Marketplace Payout and Settlement Software: Where Does the Money Actually Sit Between the Buyer and the Seller?

The moment you split other people's money, you are running a financial system

Most platforms cross this line without noticing. You start by charging a buyer and paying a seller, which feels like two API calls. Then a buyer disputes an order the seller was already paid for. Then a refund lands after the seller's balance has hit zero. Then a seller abroad wants payout in their own currency at a rate that does not match the one you quoted. Then a tax authority wants an annual statement per seller. Each is a small feature. Together they are a ledger, and if you do not have one, your finance team is the ledger.

The scene that gets these projects funded is month end. Finance has three numbers that should agree and do not: what the payment provider says settled to your bank, what the order system says was collected, and what the payout records say went to sellers. The gap is a few thousand dollars, changes every month, and is written off to a suspense account after two days of chasing. Nobody can say whether it is FX rounding, a refund posted twice, a retried payout, or a genuine loss. The write-off is small. That it cannot be explained is the actual problem, because it means you cannot prove seller balances are correct, and those balances are money you owe.

The tools involved are usually Stripe Connect or Adyen for Platforms doing the money movement, the order system holding the commercial truth, a spreadsheet for reserves and adjustments, and an accounting package downstream. Those payment platforms are excellent at what they do and this article is not an argument against them. The argument is about who holds the ledger: the authoritative record of what every seller has earned, what has been withheld, what has been paid and what is still owed. Providers hold their own view of that, scoped to what flowed through them, and it will never include the refund you issued as goodwill from your own funds or the marketing fee you agreed off-cycle.

The order system is not a ledger, and treating it as one is the root cause

An order table with a paid flag and a payout reference feels adequate until you have to answer a question sideways. What was seller 4,281's balance on 14 March. What made up the payout of $8,417.22 they received on the 20th. Each requires reconstructing history from mutable rows, and mutable rows do not remember.

What a custom build does: double entry, properly. Every economic event writes balanced entries against accounts. A sale credits the seller's payable account and credits your commission revenue. A refund reverses. A chargeback debits the seller and moves the amount to a dispute account. A payout debits the payable and credits cash in transit until the provider confirms. Nothing is ever edited, only reversed with a new entry, so any historical balance is a query rather than an archaeology project.

Two details separate a real implementation from a cosmetic one. Idempotency on every entry, keyed to the source event, because payment webhooks arrive twice and a duplicate credit is money you pay out and never recover. And an amount stored as integer minor units with an explicit currency, never a float, because floating point arithmetic on money produces exactly the unexplainable cent differences you are trying to eliminate. That sounds like trivia and it is the difference between balancing and not.

Reserves, returns and the seller whose balance goes negative

Every marketplace eventually pays a seller for an order that later reverses. If the seller is still trading, you net it. If they have gone quiet, you hold an unsecured receivable against a small business abroad, and you will not collect it.

Reserve policy is the control, and it should be graduated rather than uniform. A rolling reserve holding a percentage of volume for a defined period suits new sellers. A holdback until delivery confirmation suits categories with high not-received rates. A fixed minimum balance suits sellers with a poor dispute record. Reserve level is a risk decision that should respond to behaviour, tightening when the dispute rate rises and releasing as a seller establishes history.

What a custom build does: reserve as a first class account per seller with its own entries, so a seller statement shows exactly what is held, why, and when it releases. Negative balances trigger a defined recovery sequence: net against future earnings, then attempt a debit against a stored payment method where you have that authority, then hold payouts, then write off at a threshold rather than chasing forever. Every step is logged. Sellers dispute reserves more than any other line, and a statement that shows the calculation ends most of those conversations before they start.

Multi currency turns a rounding question into a policy question

The moment sellers are paid in a currency other than the one buyers paid in, you have to answer questions that have no default correct answer. Who bears FX risk between the sale and the payout. What rate applies, and at what moment is it struck. Do you quote sellers a guaranteed rate at sale time and absorb the movement, or pass through the rate at payout. Where does the FX spread show up in your own accounts.

These are commercial decisions and they must be explicit, because whichever you choose, a seller will eventually ask why they received less than they expected. What a custom build does: the ledger holds entries in the transaction currency and in your functional currency, with the rate and its timestamp on the entry, and FX gain and loss books to its own account rather than disappearing into the seller payable. Payouts then route by corridor, since ACH, SEPA and a partner rail like Hyperwallet or Trolley have different costs, speeds and failure behaviours. Failure handling matters more than people expect: a failed payout must return funds to the seller's balance atomically, not leave them in limbo while support investigates.

Tax reporting is a deadline you cannot negotiate

Platforms that settle payments to sellers in the United States generally have Form 1099-K reporting obligations as third party settlement organisations, and the reporting thresholds have been subject to change, so confirm the current position with your tax advisers rather than relying on any published figure. In the European Union, DAC7 requires digital platforms to collect and report seller information and income, with equivalent rules following the OECD model in other jurisdictions including the United Kingdom.

The operational failure is always the same and it is not the filing. It is that you did not collect valid tax identification from sellers at onboarding, and now, in January, you are chasing 4,000 people for a tax form while a deadline runs. The fix is boring and it works: collect and validate tax identity before the first payout, not before the first listing, so the seller has an incentive to complete it. Then run validation continuously rather than at year end.

What a custom build does: tax identity as a gate on payout eligibility, with the reportable amounts accumulating in the ledger continuously and by jurisdiction, so the annual file is a report rather than a project. Corrections need to be a supported flow, because they will happen and re-filing by hand across thousands of sellers is not viable.

Reconciliation to the provider settlement file is the whole point

Everything above only counts if you can prove it against the money that actually arrived. Payment providers send settlement files with their own view of transactions, fees, refunds, disputes and payouts. Your ledger has its view. Reconciliation is matching them line by line and explaining every difference.

What a custom build does: automated matching on provider references, a break queue for anything unmatched, and an ageing report so a break cannot quietly persist. The target that matters is not zero breaks, which is unrealistic, but zero unexplained breaks older than a defined number of days. Fee differences, timing differences across a settlement boundary and FX rounding are all normal and should be classified automatically. What you are hunting is the break with no category, because that is where a real defect lives. Once this runs daily rather than monthly, month end stops being an event.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A first release with a double entry ledger, split calculation, reserve accounts, payout scheduling through an existing provider, seller statements and daily reconciliation runs $90,000 to $190,000 and ships in 14 to 20 weeks. A full platform adding multi currency with FX policy, multiple payout corridors, negative balance recovery, tax identity collection and annual reporting, dispute handling and a finance operations console runs $240,000 to $600,000 phased over 9 to 15 months.

What drives cost up here: the number of payout corridors and currencies, since each rail has its own failure modes and file formats. Tax jurisdictions, because each reporting regime is separate work. Whether you take custody of funds at any point, which is a regulatory question before it is a technical one and can bring money transmission licensing in the United States or payment institution requirements in Europe into scope. Get that answered by counsel early, because it determines the architecture rather than decorating it. And migration, since moving live seller balances between systems has to be provably exact.

What keeps cost down: one currency, one payout rail, your existing provider as holder of funds, and reconciliation from day one. Building the ledger correctly at the start is dramatically cheaper than retrofitting it after two years of order rows.

When Stripe Connect on its own is enough

Buy, and stop reading, if you have under a few hundred sellers, one currency, one country and a straightforward commission. Stripe Connect and Adyen for Platforms handle splits, payouts and much of the compliance burden, and building your own ledger to serve 200 sellers is engineering vanity. Hyperwallet and Trolley are sensible additions when you need payout reach into markets your primary provider does not serve well.

Build the ledger when two or more of these are true. Finance cannot explain the difference between provider settlement and your own records. Sellers query balances and you cannot show the calculation. You have reserves, adjustments, marketing fees or off-cycle credits that live outside the payment provider and therefore outside its view. You operate multiple currencies and FX gain and loss is not booked anywhere identifiable. Or you are approaching tax reporting obligations in more than one jurisdiction. Note that building the ledger does not mean leaving your payment provider. The usual and correct outcome is that the provider keeps moving money while you own the record of what is owed.

How to choose a developer for settlement software

Ask them how they store money. If the answer is not integer minor units with an explicit currency on every amount, and they cannot explain why floats are unacceptable here, they should not build your ledger.

Ask what happens when a webhook is delivered twice. Idempotency keyed to the source event should be the first thing out of their mouth, not something they add after the first duplicate payout.

Ask how a historical seller balance is answered. In an immutable double entry design it is a query over entries up to a date. If the answer involves recalculating from current order rows, the design cannot support an audit or a dispute.

Ask them to walk through reconciliation against a provider settlement file, including how breaks are categorised and aged. A team that has done this has opinions about timing differences at settlement boundaries.

Ask who owns the code and the ledger data, and settle it before kickoff. This is the record of money you owe other people and it cannot sit in a supplier's account. At Digital Heroes the client owns the repository from the first commit.