Is there a link between SaleAgreements and OrderTransaction?

GraphQL Admin API Troubleshooting
1

Hi There,

Wondering if there is a node that provides the gid of the OrderTransaction on a SaleAgreements?

Struggling to connect a SalesAgreement (or ReturnAgreement/Etc) to a particular set of OrderTransaction definitely, which we need to in order to downstream to accounting package.

I would have thought there would be an array of transactionId’s against a Agreement somewhere to associate…

Regards,

Chris

2

Hi,

I completely understand the struggle! Trying to cleanly reconcile Shopify’s API data downstream to an accounting package can be a major headache when the relational IDs don’t perfectly map up.

To answer your question directly: No, the SalesAgreement object itself currently does not expose a direct array of OrderTransaction GIDs. Shopify separates these concepts by design—the agreement represents the record of exchange (the intent of what was sold/returned), while the transaction represents the actual movement of money.

However, depending on the type of agreement, here is how you can confidently connect them:

1. For Returns (ReturnAgreement)

There is great news on this front! As of a January 2026 API update, Shopify added a direct transactions connection natively to the Return object. Because a Return generates the ReturnAgreement, you can now query the return directly to get the specific transaction IDs (refunds, or captured payments for POS returns) without having to guess based on amounts and timestamps.

Example Query:

GraphQL

query {
  return(id: "gid://shopify/Return/123") {
    transactions(first: 5) {
      edges {
        node {
          id
          kind
          status
        }
      }
    }
  }
}

2. For Initial Orders (SalesAgreement)

For standard sales agreements generated when an order is first placed, the transactions are tethered to the parent Order object (Order.transactions). To connect them, you will generally need to:

  • Query the Order to fetch both its agreements and its transactions.

  • Correlate them chronologically using the happenedAt field on the agreement and the createdAt field on the transaction.

  • Cross-reference the financial totals to ensure they balance for your accounting sync.

It is definitely not as neat as a simple array of IDs on the agreement itself, but pulling the transactions directly from the Return object should solve the most complex part of the accounting logic.

3

hey @Ahmad_Abbas,

Thanks for your detailed explanation on this, this is definitely what I am seeing as well insofar as the linking. I think (personally) that the original OrderAgreement should have an array like the returnAgreement that includes the payments intially associated with it.

The other transaction set we are dealing with is orderEditAgreement as well, which for Possibilities includes a OrderTransaction (for the difference).

Also correlating timestamps for OrderAgreement is not perfect as it is possibility out by a second or so based on the data I am seeing.