# Merchant settlement records: system map | SourceX

Canonical: https://refer.sourcex.si/guides/merchant-settlement-reconciliation-records-across-systems
Last updated: 2026-10-19

Five references join one merchant settlement reconciliation item across systems: the payment provider's transaction or refund ID; the payout ID that ties a group of transactions to one bank deposit; the retailer's own order or invoice number, which joins the provider record to billing; the ledger journal number; and the adjustment ID that records who explained a difference. Those references live in five places, the provider portal, the bank statement, the billing system, the general ledger and the month-end close file, and the chain breaks wherever one system stopped storing its key.

This system map is part of the [merchant settlement reconciliation guide](/guides/workflow-merchant-settlement-reconciliation), which explains why the exception records matter. Here the job is narrower: for each record, where it sits, the field that joins it to the next and who knows it best. It is written for payments integration advisors who need to describe a retailer's evidence without handling any of it.

## Five places, two vocabularies

Money and orders are recorded by systems that were never designed together, and each names things its own way.

**Payment provider portal.** Transactions, refunds and the payouts that group them. The provider's own reports are organized around its IDs. Stripe, for example, documents that a payout ID can be passed to a balance transaction request to return only the transactions behind that payout.

**Bank statement.** The deposit as the bank booked it. Many banks deliver this as an ISO 20022 camt.053 message, the bank-to-customer statement that reports booked entries and balances on an account. It shows an amount, a date and a short reference, and rarely anything about orders.

**Billing or order system.** The charge, the refund request and the credit note, keyed by order or invoice number.

**General ledger.** Journals posted from billing, sometimes one per order, sometimes one summary per day.

**Close file.** The spreadsheet or reconciliation tool where finance compares expected and received amounts, records each difference and logs who approved the adjustment that cleared it.

## Record, linking key and owner

| System | Record | Linking key | Who knows it best |
|---|---|---|---|
| Provider portal | Transaction or refund | Transaction or refund ID, plus the order number passed in as reference | Payments operations director |
| Provider portal | Payout grouping | Payout ID listing the transactions it contains | Payments operations director |
| Bank | Deposit entry | Amount, date and payout reference where present | Treasury manager |
| Billing system | Charge, refund request or credit note | Order or invoice number | Revenue operations lead |
| General ledger | Journal entry | Journal number citing the billing document | Controller |
| Close file | Difference and approved adjustment | Adjustment ID citing refund ID, payout ID, journal number and approver | Controller or reconciliation lead |

The right column is about knowledge, not authority. Who can authorize a licensing discussion is a separate question, answered in the [who can license decision tree](/questions/who-can-license-merchant-settlement-reconciliation-records).

## One fully joined case (Illustrative)

Invented for this page. A fictional 380-person online furniture retailer takes card payments through one provider whose daily cutoff is 23:00. On the last day of October a customer receives a $386.50 partial refund on order ORD-77120 for a damaged chair. Customer service issues it at 23:52.

| Step | Record | System | Reference that joins it to the next |
|---|---|---|---|
| 1 | Credit note CN-2291 for $386.50, October 31 | Billing | Order ORD-77120 |
| 2 | Journal JE-10418 books the refund in October | Ledger | Cites CN-2291 |
| 3 | Refund RF-4471 at 23:52 with reference ORD-77120 | Provider portal | Refund ID and order number |
| 4 | October 31 payout PO-5529 excludes the refund | Provider portal and bank | Payout ID |
| 5 | October close: deposit $386.50 above what the ledger expected; difference logged | Close file | Cites PO-5529 |
| 6 | November 1 payout PO-5530 includes RF-4471 | Provider portal and bank | Payout ID |
| 7 | Adjustment ADJ-0931 approved by the controller: refund timing across month end | Close file | Cites RF-4471, PO-5530 and JE-10418 |

Read down the right column: one order, one credit note, one refund, two payouts and an adjustment that names every reference. The month-end date makes this harder than an ordinary day-to-day timing gap, because the difference has to be carried as a reconciling item from October into November and cleared in a different accounting period from the one where it opened. A same-month version of the cutoff problem is worked through in the [parent guide](/guides/workflow-merchant-settlement-reconciliation).

## Five places the chain snaps

**Order number never sent.** If billing did not pass the order number to the provider, step 3 joins step 1 only by amount and time, which fails as soon as two refunds share an amount.

**Payouts made by hand.** When finance moved money out manually instead of on the provider's automatic schedule, the provider may hold no grouping that says which transactions a payout covered. For those years, steps 4 to 6 depend entirely on the retailer's own close files, so ask when the switch happened.

**Daily summary journals.** A ledger that posts one total per day with no billing reference loses step 2's link to a specific credit note.

**Close files saved over.** A spreadsheet overwritten every month keeps the current balance and loses the October reasoning.

**Adjustments with no reference.** An entry that says only "timing" keeps the arithmetic and drops the explanation. It is often the missing link, and it is the one that makes an exception history worth reviewing.

The ledger side of the same tie-out is covered on the [general ledger reconciliation page](/resources/mcp/mcp-general-ledger-reconciliation), and the [workflow map template](/resources/workflow-map-template-business-records) is a general format for drawing a map like this one.

## Questions that fill the map

Put these to the payments operations director or controller. Each asks about a field or a habit, never a file.

1. Does billing pass the order or invoice number to the provider with every charge and refund?
2. Which providers in which years, and were payouts automatic or manual in each period?
3. Are payout reports stored outside the provider portal, and for how long?
4. Does the ledger post per order or as a daily summary?
5. Are close files kept by period, and does each adjustment cite a refund, payout or journal reference?
6. Is a provider change or ledger migration planned? The [preservation guide](/guides/preserve-merchant-settlement-reconciliation-records) covers that event.

Write "unknown" until someone at the company confirms each answer.

## What the map leaves open

The map describes fields and who knows them; it does not settle rights. Card details stay out of any discussion and out of the partner's hands, and provider agreements may affect what the retailer controls. [Why data rights matter](/proof/why-data-rights-matter) explains why SourceX reviews that first.

The introduced company needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Partners sign the Channel Partner Agreement before submitting; the first valid introduction within the 90-day window is credited when the company submits a verified application. Buyer interest, the rights result, the preparation needed and any offer stay unknown until SourceX reviews the opportunity.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If the map shows a retailer whose adjustments still cite the refund, payout and journal they explain, [register as a partner](/register), check the company on [who qualifies](/who-qualifies) and read the [program terms](/terms) before introducing its payments operations director.

## Sources

- https://refer.sourcex.si/terms
- https://docs.stripe.com/payouts/reconciliation
- https://www.iso20022.org/iso-20022-message-definitions?search=camt.053