Marketplace payouts without reconciliation chaos

Why this matters

A marketplace runs two financial systems at once: the PSP’s view of money in and out, and the marketplace’s view of who owes whom. These two views are not naturally consistent, and the gap between them is where reconciliation chaos lives.

In the early months of a marketplace, the gap is small and a finance lead can close it with a CSV and a Saturday. By month 18, the marketplace is processing payments through two or three PSPs across Bre-B, PSE, cards, Pix, SPEI, and wallets, splitting revenue across thousands of sellers, handling refunds and chargebacks per seller, and reconciling settlement cycles that don’t align with payout cycles. The Saturday CSV is no longer enough. By month 36, finance is a six-person team whose week is structured around PSP exports, and sellers are calling support about payout delays nobody can explain.

The fix is architectural, not procedural. A marketplace that owns its own ledger, a system of record for every cent that moves, attached to seller balance accounts, turns reconciliation from a monthly fire-drill into a continuous, automatic process. The teams that do this early grow without finance scaling linearly. The teams that don’t, eventually have to do this migration anyway, but under pressure.

What goes wrong

The standard failure modes are predictable:

• PSP-level truth treated as marketplace-level truth. The PSP knows that USD 100 came in. It does not know that USD 70 belongs to Seller A, USD 25 to Seller B, and USD 5 to the platform. Encoding that split in code instead of in a ledger means every refund, chargeback, or adjustment has to re-derive the split from scratch.
• Split logic in checkout, not in a ledger. When the split lives in the payment flow only, you cannot easily answer “what is Seller A’s balance right now.” You can only answer it by replaying every transaction.
• Settlement cycles ignored. PSPs settle on T+1 to T+14 depending on rail. Marketplaces often promise sellers payouts on a fixed cycle (weekly, biweekly). When those cycles don’t align, the marketplace ends up either fronting cash or delaying sellers, and neither is sustainable.
• Refunds and chargebacks handled at the PSP layer. When a refund or chargeback hits, the PSP claws back the gross amount. If the seller has already been paid out their share, the marketplace eats the gap. Without a seller-balance ledger, there is no clean way to net this against future earnings.
• Multi-PSP without unified ledger. Adding a second PSP doubles reconciliation work. Adding a third triples it. The cost grows superlinearly because each PSP has different export formats, refund mechanics, and settlement timing.
• Manual seller payouts. Finance generating CSVs of “who to pay” by hand is the standard pattern at marketplaces under USD 5M GMV. It does not scale and it is where errors hide.
• No source of truth for tax and withholding. LATAM marketplaces increasingly carry tax-collection responsibilities (VAT, withholding, retention). Without a ledger, computing these correctly per seller per period is nearly impossible.

Operating model

The operating model for marketplace payouts is a single principle: the ledger is the source of truth. The PSP is an event source, not a source of truth.

A marketplace that operates this way can grow from USD 1M to USD 100M GMV without scaling finance team headcount linearly. A marketplace that doesn’t, hires a finance person every USD 5M of GMV and still falls behind.

Recommended approach

The principles that hold across LATAM marketplaces:

Build the ledger before adding the second PSP. The reconciliation pain of multi-PSP without a ledger is enough on its own to justify the build. Doing the ledger first means the second PSP integration is mechanical, not chaotic.

Use double-entry from day one. Single-entry ledgers feel simpler but make reconciliation harder and make audits painful. Every event is a pair of entries: credit somewhere, debit somewhere.

Seller balances should be queryable in real time. Sellers asking “what is my balance” should get a current answer, not “we’ll get back to you after the monthly close.” This is also what enables seller-facing dashboards.

Reconcile daily, not monthly. A daily reconciliation pipeline that surfaces exceptions immediately is the difference between catching errors on day one and catching them at month-end when the volume is overwhelming.

Handle refunds and chargebacks at the seller layer. When a refund hits, debit the seller’s balance immediately. If the seller has a positive balance, the refund nets against it. If not, the marketplace fronts the cash and the seller balance goes negative until earnings catch up.

Plan working capital deliberately. The gap between PSP settlement and seller payout is a real cost. Marketplaces that pretend it isn’t end up either delaying sellers or running negative on cash. Working capital should be a line item, sized to expected GMV.

Tax and withholding as ledger entries. Whatever the local regime requires, encode it in the ledger as separate entries. This way the tax position is always current and auditable.

Example architecture

A reference architecture for a marketplace payouts and reconciliation stack:

Buyer payment (PSP A / PSP B / Bre-B / Pix / SPEI)
    ↓
PSP webhook → ledger entries
    → credit: seller balance (net of fee)
    → credit: platform balance (fee)
    → credit: tax / withholding account (if applicable)
    ↓
Seller balance accounts (real-time, queryable)
    ↓
Payout scheduler (per seller cycle: weekly / biweekly)
    → reads seller balance
    → debits seller balance
    → debits platform clearing
    → triggers payout via local rail (Bre-B / Pix / SPEI / ACH)
    ↓
Refund / chargeback events
    → debit: seller balance
    → debit: platform balance (fee reversal)
    → debit: tax account (reversal)
    ↓
Daily reconciliation
    → PSP settlement file vs ledger
    → exceptions surfaced for review
    ↓
Reporting: GMV, take rate, seller balances, working capital position

The two pieces that matter most: the seller balance account (because it makes every other operation answerable in real time), and the daily reconciliation pipeline (because monthly reconciliation always falls behind).

Metrics to watch

Reconciliation cycle is the operational hygiene metric. Anything longer than 24 hours means exceptions are stacking up faster than the team can resolve them.

Unresolved balance % is the trust metric: the fraction of GMV that cannot currently be attributed cleanly between platform, seller, and tax accounts. Above 0.5%, finance starts losing confidence in the books.

Finance hours per million GMV is the metric that tells you whether the ledger architecture is paying off. In a marketplace without a ledger, this number grows with GMV. In a marketplace with one, it shrinks.

What to read next