Skip to main content

Bank reconciliation (transfer report entries)

List Transfers, Get Transfer, and Transfer Events return the aggregate payout only — amount, status, destination bank, and settlement dates. ERP bank reconciliation usually needs the payments and fees inside that payout so deposits and fee withdrawals can be matched in the ERP.

That line-item detail is available on the Transfer Report Entries endpoint:

GET /transfers/{transferId}/report/entries
Authorization: Bearer {access_token}
X-CUSTOMER-ID: {merchant_customer_id}

See List Transfer Report Entries and Get Transfer Report.

Prerequisites​

  1. Merchant API credentials (same OAuth client credentials + X-CUSTOMER-ID used for other Transfer calls).
  2. Transfer reports enabled for the merchant (settings.transfers.report.enabled). If the feature is off, report endpoints return 401 insufficientFeatureAccess.
  3. A transfer that has reached posted or paid, with a transfer report in completed (or reversed) status.

End-to-end connector pattern​

Transfer webhook (flat amount)
  → when resource.status is posted or paid
  → GET /transfers/{id}/report   (retry until status is completed)
  → GET /transfers/{id}/report/entries
  → map each entry into the ERP bank feed / cash management records

1. Detect the payout​

Subscribe to Transfer Events, or poll List Transfers / List Transfers (filtered). Use resource.id (the transfer ID) as your idempotency key for the settlement batch.

The webhook / transfer object does not include the constituent payments — that is expected.

2. Wait for the transfer report​

Call Get Transfer Report:

GET /transfers/{transferId}/report

The report can lag the Transfer webhook. Retry until status is completed (or reversed). Calling report entries too early returns 404 with an explanation that the transfer report is not available yet.

3. Fetch line items​

GET /transfers/{transferId}/report/entries

Example response shape:

{
  "results": [
    {
      "resourceType": "fee",
      "resourceId": "0t5y7jvdrji3mhf01viihbjf",
      "resourceAmount": "1.00",
      "relatedId": "fupdrurfdwz3pua0l1eoy49s",
      "relatedType": "payment",
      "transferAmount": "-1.00",
      "currency": "USD",
      "payerId": "fsivwpg417h2ivc5oi8h6gbi",
      "payerName": "Christina C"
    },
    {
      "resourceType": "payment",
      "resourceId": "fupdrurfdwz3pua0l1eoy49s",
      "resourceAmount": "5000.00",
      "transferAmount": "195.48",
      "currency": "USD",
      "payerId": "fsivwpg417h2ivc5oi8h6gbi",
      "payerName": "Christina C"
    }
  ],
  "count": 2,
  "settings": {
    "limit": 999999,
    "offset": 0
  }
}

4. Map entries in the ERP​

FieldTypical ERP use
resourceTypeDocument type — payment ≈ bank deposit / credit; fee ≈ bank withdrawal / debit
resourceIdDocument number (DOCNO) — Paystand payment or fee ID for auto-match against GL / AR cash application
transferAmountSigned amount — positive for payment deposits, negative for fees
currencyCurrency of the bank entry
dateUTC / entryDateBank feed posting date
payerId / payerName / payerEmailOptional enrichment for X3 / Sage 100 cash receipts
relatedId / relatedTypeOn fee rows, links the fee back to its payment

Summing transferAmount across entries should reconcile to the parent transfer's aggregate amount (within rounding for multi-currency edge cases).

Optional CSV export of the same rows: GET /transfers/{transferId}/report/csv.

How this relates to List / Get Transfer​

SurfaceAggregate payout?Payment/fee line items?
GET /transfers/all, GET /transfers/{id}YesNo
Transfer webhooksYesNo
GET /transfers/{id}/reportSummary / readinessNo
GET /transfers/{id}/report/entries—Yes

No new Paystand X API surface is required beyond these classic Transfer report routes — they use the same /v3 base URL and merchant credentials.