# Settlement records retention timeline | SourceX

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

Before a processor migration, list each settlement record class with four facts: where it lives, how far back it goes, who administers it and the documented date access ends. A migration moves future payments, not the past. In the Illustrative plan below, transaction API access and portal settlement reports go first, then the reconciliation tool and approver mailboxes, while ledger journals survive. Keeping any of it is a decision for the records owner and counsel, not the advisor.

This timeline is part of the [merchant settlement reconciliation guide](/guides/workflow-merchant-settlement-reconciliation). It is written for payments integration advisors watching a business change processors, and it treats retention as a sequence of dated events rather than a list of files.

## What the migration path actually carries

Processor migrations are built to keep customers billing. Stripe, for example, documents that on request it prepares an encrypted file of customer card details, email addresses and metadata and sends card data only to a PCI DSS Level 1 compliant processor. That protects subscriptions. It says nothing about daily settlement files, payout reports, dispute records or the transaction log, and in practice those stay behind with the old processor.

So the question for a business is not "will our data move?" but "which history stays reachable after the old contract ends, and for how long?" The answer sits in the old provider agreement and the company's own cutover plan.

## The timeline, from notice to year one (Illustrative)

The plan below is invented for a fictional 340-person subscription merchant leaving one processor. Day numbers count from the signed termination notice. Real dates must come from the contract or the cutover plan; nothing here is a typical provider's schedule.

| Day | Event | Record class affected | What is lost if nothing is decided |
|---|---|---|---|
| 0 | Termination notice signed | None yet | Nothing; this is the moment to inventory |
| 30 | New processor goes live for new sales | Transaction log keeps growing on both sides | Nothing yet, but two sources now exist |
| 60 | Old API keys revoked | Transaction log with merchant references | Bulk access to refund and chargeback detail |
| 90 | Old portal login closed at contract end | Daily settlement files, payout reports | Downloadable daily settlement history for older years |
| 120 | Bank feed remapped to the new provider | Payout records on bank lines | The payout ID stored beside each bank deposit |
| 180 | Reconciliation tool subscription ends | Period worksheets, with sign-off | The variance record and its open and close dates |
| 365 | Departed approvers' mailboxes purged under policy | Adjustment approvals sent by email | Who approved each adjustment, and why |
| Ongoing | ERP retained under the finance retention schedule | Ledger journals | Usually nothing, unless the chart of accounts is restructured |

Read the table from the bottom up and the pattern is clear: the record that survives longest, the ledger, explains the least on its own. The records that explain an exception, the settlement file, the period worksheet and the approval, are the ones with the shortest lives.

## What disappears first, and why it matters

**Transaction-level references.** The company's own reference on a refund is what ties a ledger journal to the provider's record of it. Once API access ends, those references may survive only inside whatever reports were downloaded.

**Deposit-to-sales links.** When treasury remaps the bank feed to the new provider, the identifier that tied each incoming deposit to a group of sales can stop appearing on bank lines, and where the link was added by the feed mapping rather than stored on the statement itself, older lines can lose it too. If nobody captured it elsewhere, the period worksheet is the only place the link exists, and losing the period worksheet loses the explanation.

**Approvals in email.** Adjustment approvals often live in inboxes. Mailbox retention policies for departed staff can remove them on a schedule nobody in finance tracks.

## Tax retention is a floor, not the plan

Finance teams often anchor on tax rules. The IRS sets a default of 3 years for supporting records, 7 years where a bad debt deduction or worthless securities loss is claimed, and at least 4 years for employment tax records, and notes that insurers or creditors may require longer. Those periods govern what a company must keep for tax purposes. They do not keep a provider portal open, and they say nothing about whether period worksheets were saved with their sign-off. A business can be fully compliant on tax retention and still unable to explain a single historic variance.

## Who approves keeping each record

| Record class | Administered by | Approves retention or export |
|---|---|---|
| Transaction log and API data | Payments engineering | CFO, with counsel on processor terms |
| Daily settlement files | Payments operations | CFO, with counsel on provider terms |
| Payout records and bank feed | Treasury | Controller or CFO |
| Reconciliation period worksheets | Controller | Controller, under finance policy |
| Adjustment approvals in email | IT, under mailbox policy | General counsel and CFO |
| Ledger journals | ERP owner | Covered by existing finance retention schedule |

Record a deadline only when it is documented: a termination date, a notice period, a cutover milestone. Do not recommend downloading or keeping anything the company has not authorized. If the company carries merchant cash advances, funders' agreements may restrict asset transfers; see [merchant cash advance UCC lien restrictions](/questions/merchant-cash-advance-ucc-lien-restrictions). The [data controller versus data processor comparison](/compare/data-controller-vs-data-processor) helps when someone asks whose records the provider holds.

## Qualification and what stays unknown

An introduced company needs 50+ full-time employees at peak (contractors excluded), a 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 introductions and stay at metadata level throughout.

Until SourceX reviews the opportunity, nobody knows which preserved records the company has rights to license, how processor terms apply, how much preparation they need or whether buyers want them. The [decision tree on who can license these records](/questions/who-can-license-merchant-settlement-reconciliation-records) finds the signer, the [referral brief template](/resources/merchant-settlement-reconciliation-referral-brief-template) has a field for the access deadline, and [reconciliation exceptions as training data](/data-types/reconciliation-exceptions-ai-agent-training-data) explains why the history matters. Retail merchants are also covered on the [e-commerce page](/industries/ecommerce).

## 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 a business's timeline shows years of settlement history that will become unreachable on a documented date, [register as a partner](/register), check the company against [who qualifies](/who-qualifies) and read the [program terms](/terms) before you raise it with the CFO.

## Sources

- https://docs.stripe.com/get-started/data-migrations/pan-export
- https://www.irs.gov/businesses/small-businesses-self-employed/how-long-should-i-keep-records
- https://refer.sourcex.si/terms