Integration via API - Step 6: Reconcile
Reconciliation
Widget Co. employs a comprehensive hybrid approach to help achieve accurate debiting and crediting of all receivables and disbursements. This methodology maintains consistent alignment between the account ledger and its corresponding transaction log:
- Intraday Payables Reconciliation: Outgoing payments are systematically matched with account ledger debits.
- Intraday Receivables Reconciliation: Incoming account ledger credits are reconciled against open invoices and treasury cash movements.
- End-of-Day (EOD) Reconciliation: Internal ledger records are balanced with those of the TxB account ledger at the close of each business day.
- Exception Management: Manual verification is conducted for ad-hoc transactions through diligent API polling. The following sections present examples of these processes utilizing payment data from “Step 3: Payout.” These examples include detailed processes for batch payments, such as ACH or SEPA, as well as wire payments, including Fedwire or CHAPS.
Intraday Payables Reconciliation for Batch Payments
Batch or low-value payment systems include:
- US: ACH
- UK: BACS
- EU: SEPA
Widget Co. utilises the TxB Transactions API to reconcile outgoing batch payments. Taking the batch payment initiated at “Step 3: Payout” as an illustrative example, the following outlines the reconciliation process. Key payment details:
- Payment Request ID: PaymentReqID0000001, total amount: USD 406.00
- Payment #1 End-To-End ID: TxE2EID000001, amount: USD 106.00
- Payment #2 End-To-End ID: TxE2EID000002, amount: USD 300.00 The Widget Co. account must display a single debit representing the total value of all transactions within the batch. In this instance, the debit will be USD 406.00.
Request GET https://api.test.txb.gs.com/v2/reports/transactionReports?referenceNumber=250000079648&businessDate=2026-01-27
Response
{
"transactions": [
{
"postingDate": "2026-01-27T15:06:52Z",
"valueDate": "2026-01-27",
"transactionType": "ACH Credit Payment",
"transactionTypeCode": {
"domainCode": "PMNT",
"familyCode": "ICDT",
"subFamilyCode": "ACDT"
},
"debitOrCredit": "DEBIT",
"amount": 406.00,
"amountCurrency": "USD",
"identifiers": {
"paymentRequestId": "PaymentReqID0000001",
"paymentEndToEndId": "null",
"gsUniquePaymentId": "GPB2533118886542",
"railReferenceId": {
"rail": "ACH”
}
}
}
]
}
//Only relevant fields added for easy reading
// Key Reconciliation Fields are: "paymentRequestId": "PaymentReqID0000001" and "amount": 406.00Occasionally, a payout batch (e.g. BACS, SEPA CT) may be divided into two or more debit entries within the account. In such instances, the Transaction API response will return the corresponding batch debit entries and will have the same paymentRequestId in the identifiers.
Intraday Payables Reconciliation for Wire and Real-Time Payments
High-value wires and real-time payment systems include
- US: Fedwire and Real Time Payments (RTP)
- UK: CHAPS and Faster Payments (FPS)
- EU: Target 2 and SEPA Instant
Widget Co. also utilizes the TxB Transactions API to reconcile outgoing wire payments. In this occasion, taking the wire payment initiated at "Step 3: Payout" as the example, here is reconciliation process.
Widget Co. initiated an API payments request at "Step 3 Payout" combined of two payments
- Payment Request ID PaymentReqID0000002, total amount of USD 6012.00
- FedWire Payment #1 End_To_End ID TxE2EID000021, amount USD 4012.00
- FedWire Payment #2 End_To_End ID TxE2EID000022, amount USD 2000.00 In this instance, the Widget Co. account must display one debit for each payment in the Originate Payment API request, one debit for USD 4012.00 and a second debit for USD 2000.00.
Request GET https://api.test.txb.gs.com/v2/reports/transactionReports?referenceNumber=250000079648&businessDate=2026-01-27
Response
{
"transactions": [
{
"postingDate": "2026-01-27T15:06:52Z",
"valueDate": "2026-01-27",
"transactionType": "Outgoing Wire",
"transactionTypeCode": {
"domainCode": "PMNT",
"familyCode": "ICDT",
"subFamilyCode": "DMCT"
},
"debitOrCredit": "DEBIT",
"amount": 4012.00,
"amountCurrency": "USD",
"identifiers": {
"paymentRequestId": "PaymentReqID0000002",
"paymentEndToEndId": "TxE2EID000021",
"railReferenceId": {
"rail": "FEDWIRE"
}
}
},
{
"postingDate": "2026-01-27T15:06:52Z",
"valueDate": "2026-01-27",
"transactionType": "Outgoing Wire",
"transactionTypeCode": {
"domainCode": "PMNT",
"familyCode": "ICDT",
"subFamilyCode": "DMCT"
},
"debitOrCredit": "DEBIT",
"amount": 2000.00,
"amountCurrency": "USD",
"identifiers": {
"paymentRequestId": "PaymentReqID0000002",
"paymentEndToEndId": "TxE2EID000022",
"railReferenceId": {
"rail": "FEDWIRE2"
}
}
}
]
}
//Only relevant fields added for easy reading
// Key Reconciliation Fields for the payments and the transactions entries are:
// 1. "paymentEndToEndId": "TxE2EID000021" and "amount": 4012.00
// 2. "paymentEndToEndId": "TxE2EID000022" and "amount": 2000.00Intraday Receivables Reconciliation
The Widget Co. Accounts Receivables Team is responsible for reconciling incoming payments credited to virtual accounts with issued invoices and treasury cash movements. This reconciliation process leverages data from the originating bank, such as an Invoice Id, to accurately identify specific payments. While both Webhooks and the Transactions API offer solutions for receivables reconciliation, Widget Co. has opted for Webhooks to avoid routine data polling. The team utilizes the following attributes during reconciliation:
| Field | Description |
|---|---|
| paymentEndToEndId | Provided by the payment rail, if the sender of the payment has provided any specific identifier. |
| remittanceInfo | Accompanying each incoming payment, sender is expected to provide information like Invoice number or purpose of the payment. |
| debitOrCredit | For incoming receivables, the value should be be CREDIT. |
| amount | The amount of the received payment. |
| eventName | The event name should be INCOMING_PAYMENT.RECEIVED. |
// Webhook Payload for Incoming Credit
// only relevant fields added for easier reading
{
"deliveryId": "7687ba53-fbdf-4a86-a7f2-820d6cac946b",
"events": {
"eventId": "840773d6-0765-4e7d-88d3-b429ce34e8cb",
"eventData": {
"amount": 1530, // Individual Payment Amount
"valueDate": "2026-01-27",
"debitOrCredit": "CREDIT", // CREDIT Transaction
"debtorAccount": {
"accountNumber": "12345678",
"bankIdentifier": {
"bic": "CITIUS33XXX"
},
"accountHolderName": "TEST INC"
},
"amountCurrency": "USD",
"remittanceInfo": [
"Invoice 123" // only available if the sender has mentioned this or similar reference
],
"creditorAccount": {
"accountNumber": "123456778",
"accountHolderName": "Widget Co"
},
"transactionType": "Incoming Wire",
"gsUniquePaymentId": "GI121212121",
"paymentEndToEndId": "2JJ3144ABQW" // Individual Payment End to End ID
},
"eventName": "INCOMING_PAYMENT.RECEIVED",
"eventTimestamp": "2026-01-27T15:06:52.1769526412Z"
}
}
// Key Fields for Reconciliation:
// "amount": 1530
// "debitOrCredit": "CREDIT",
// "gsUniquePaymentId": "GI121212121"
// "paymentEndToEndId": "2JJ3144ABQW"
// "remittanceInfo": [ "Invoice 123" ]End-of-Day (EOD) Reconciliation
At the close of business (e.g., 01:00:00 a.m. UTC on T+1), Widget Co. utilizes the Transactions API to verify that all account credits and debits have been appropriately recorded. Any transaction that cannot be identified are flagged as reconciliation break and subject to further review.
// a new transaction added with "paymentEndToEndId": "TxE2EID000033" and "amount": 342.65
{
"transactions": [
{
"postingDate": "2026-01-27T16:46:52Z",
"valueDate": "2026-01-27",
"transactionType": "Outgoing Wire",
"transactionTypeCode": {
"domainCode": "PMNT",
"familyCode": "ICDT",
"subFamilyCode": "DMCT"
},
"debitOrCredit": "DEBIT",
"amount": 342.65,
"amountCurrency": "USD",
"identifiers": {
"paymentRequestId": "PaymentReqID0000003",
"paymentEndToEndId": "TxE2EID000033",
"railReferenceId": {
"rail": "FEDWIRE2"
}
}
},
.....
.....
]
}Exception Management
During the end-of-day reconciliation process, an unidentified credit was identified in Widget Co.’s “SA Cloud Services” AP virtual account. Since incoming and outgoing payments are segregated in distinct payables and receivables virtual accounts, this exception can be addressed by the Account Payables team. By leveraging the Transactions API, comprehensive payment details are accessible for manual tracking and reconciliation of the unexpected credit.
{
"transactions": [
{
"postingDate": "2026-01-27T17:06:52Z",
"valueDate": "2026-01-27",
"transactionType": "Incoming Wire",
"transactionTypeCode": {
"domainCode": "PMNT",
"familyCode": "RCDT",
"subFamilyCode": "DMCT"
},
"transactionDescription": "From: Buyer, Remittance Info: Invoice 123, Client Ref ID: 2JJ3144ABQW, GS ID: GI121212121...",
"debitOrCredit": "CREDIT", // CREDIT Transaction
"amount": 1530.00, // Individual Payment Amount
"amountCurrency": "USD",
"identifiers": {
"paymentEndToEndId": "2JJ3144ABQW", // Individual Payment End to End ID
"railReferenceId": {
"rail": "FEDWIRE"
}
},
"messagesFromOriginator": {
"remittanceInfo": [
"RTN/YR PAY REF 8988345…. / UNKNOWN BENE"
]
}
}
....
....
]
}Upon reviewing the complete transaction description, the reconciliation team observes that the originating bank supplied the following details: "RTN/YR PAY REF 8988345… / UNKNOWN BENE." This information enables the team to link the credit to a previously returned payment issued to the provider the prior week. With these records, Widget Co. is able to re-initiate the payment using the accurate beneficiary name.
Thank you for following our API integration best practices. Our goal is to ensure that these resources, alongside our comprehensive API collection, provide a seamless and efficient integration experience with Goldman Sachs Transaction Banking (TxB). Your insights are essential to our evolution; we welcome your feedback and invite you to suggest additional topics or best practices by contacting our team at Txb-Product-Solutions@gs.com.
| 1: Connect | 2: Create Account | 3: Payout | 4: Payout Status | 5: Account Status | 6: Reconcile |
|---|
Was this page useful?
Give feedback to help us improve developer.gs.com and serve you better.