Marketplace Payment Reconciliation: How to Match Platform, Payment Provider, Bank, and Your Accounting

Your book can be internally flawless and still be wrong about the world. A transfer may have failed.

A credit may have arrived smaller after fees. A refund may have been issued by hand in the payment provider's dashboard and never made it back into your system.

Reconciliation is the only mechanism that catches this. It is also the area companies usually discover in the third month after launch, when accounting refuses to close the period.

You will not find the cost of this gap in the implementation budget, because it arrives as people's time. It grows linearly with the number of transactions and never shrinks on its own.

Marketplace payment reconciliation is the routine of matching four records of the same money: what your platform recorded, what the payment provider reported, what the bank actually paid, and what your accounting will report. Each of the four is right inside its own scope, so the difference between them belongs to none of them and none of them will raise it. Reconciliation is the only mechanism that catches it.

This article breaks down:

• Why do 4 systems show 4 different numbers for the same euro?
• Which 6 classes of discrepancy do you have to handle?
• How often do you reconcile?
• Who reconciles, and who approves it?

Key insights

• Reconciliation is the only check that the money your system shows actually arrived. Internal control of the ledger cannot see the boundary at all.
• The platform, the payment provider, the bank, and accounting are each right inside their own scope.
• Provider fees are a cost rather than a discrepancy. A system that confuses the two produces an exception queue nobody reads within a month.
• The person who reconciles cannot also release payouts or post corrections, because a control exercised by the operator is not a control.

Why do 4 systems show 4 different numbers for the same euro?

The same sale exists in four places at once, and in each it means something different.

1. The platform: what should have happened

It knows what should happen: who sold what, how much the commission is, who is owed how much. It does not know whether the money actually arrived.

2. The payment provider: what it collected

It knows what it collected from buyers and how much of that it kept on its own side. It knows nothing about your commissions and nothing about which seller each amount belongs to.

3. The bank: what actually arrived

It knows exactly one thing: how much really came in and when. A single line on the statement can stand for a thousand sales, forty refunds, and a handful of fees added up into one amount.

That is because net settlement, where the provider deducts its own fees before the transfer, is the market standard.

4. Accounting: what you report, and when

It knows what you will report out of all this and in which period. It cares about the document and the date rather than about the flow.

Each of these systems is right within the limits of its own scope. The difference between them belongs to none of them.

That is why none of them will report it. Reconciliation is a process somebody runs at an agreed frequency, and no report will generate it for you.

If nobody has it in their job description, the difference does not go away. It grows until somebody runs into it by accident.

One day of sales, 4 numbers: the worked example

Take one day that we will keep coming back to. 100 orders at €1,000 each, commission 12%.

Assume for the sake of the example that your payment provider charges 1.5% of the amount collected. On that same day, three customers receive a refund of the full amount.

• The platform says: sales €100,000, refunds €3,000, net €97,000. Commission: €11,640, and €85,360 is due to the sellers.
• The payment provider says: I collected €100,000, I gave back €3,000, and I deducted €1,500 in fees. I am transferring €95,500.
• The bank will show, two days from now, one line. Settlements usually land within one to three business days, so the day of the sale and the day the money arrives are by definition different days.
• Accounting will see: commission revenue €11,640, payment handling cost €1,500, a liability to sellers of €85,360.

Notice that €97,000 ≠ €95,500, and that is not an error. The €1,500 difference is the cost of accepting payments: known, predictable, and to be posted as a cost.

It is not to be investigated as a discrepancy. Systems that do not tell the two apart produce a queue of "problems" where most items are ordinary fees.

And now, the situation this article exists for. The statement reads €95,460.

Forty euros less than the payment provider announced. The platform does not know, because it does not read bank statements.

The provider does not know, because on its side everything adds up. The bank does not know that this is a problem.

Accounting will find out in three weeks and will have no way to resolve it.

Forty euros is not the problem. The problem is that nobody sees it on the day when one phone call would still explain it.

Which 6 classes of discrepancy do you have to handle?

Reconciliation stops being detective work the moment discrepancies have names, procedures, and owners. That is the whole difference between a duty dumped on a person and a function of the system.

The last class is the most treacherous, because it concerns the outgoing side. "Paid out" has to mean "the money arrived" rather than "we generated an instruction." If your system flips the status the moment the instruction leaves, on every rejected transfer you have a seller who sees a payout in the panel, has nothing in the bank account, and you have no mechanism to detect it.

On top of that, there is a category you must never push into investigation: a difference of timing rather than of amount. An order from the last hour of the day that settles tomorrow is not a discrepancy.

If your process does not tell a shift in timing from a real difference, the exception queue fills up with noise, and within a month nobody reads it anymore.

Two things you have to settle once and write down. The tolerance: below what amount a difference is matched automatically, because explaining it costs more than the difference itself.

A technical account for unidentified funds. It needs an explicit aging rule: an item older than the agreed threshold goes to a named person for review instead of sitting there.

An account where nobody watches the age of items is a dump after a year, and by then nobody can untangle it.

How often do you reconcile the payment: daily, weekly, or at month-end?

1. Every day: the two boundaries

Did what the payment provider declared actually land in the account? And does every transaction it reports have an order on your side?

Those are exactly the two questions whose answer is cheap on the day of the event and expensive six weeks later. A discrepancy from two days ago is a phone call.

A discrepancy from two months ago is archaeology.

2. Every week: the exception queue

The review confirms that every item has an owner, an age, and a next step. A queue without those three fields is a list rather than a queue.

3. At month-end: the platform against the books

You also close the period. The rule from the previous article applies here: once a month is closed, you no longer post anything into it.

You post into the current month and point the entry at the period the event belongs to. The commission invoice goes out for a closed period, because in an open one the total is not final yet.

And one decision that is easy to forget: declare whose timestamp defines the day. Yours, the payment provider's, or the bank's?

If you do not settle that, you will spend every day reconciling a difference that does not exist, because three systems disagree about where Tuesday ends.

It helps to have a reference scale. APQC's benchmarking of 2,300 organizations puts the median month-end close at 6.4 calendar days, with the top quartile at 4.8 days or fewer.

A marketplace adds one step to that close, which ordinary eCommerce does not have. If reconciliation happens only at month-end, that step is what decides whether you close in five days or in fifteen.

Who reconciles the payment, and why can it not be the same person?

"Finance does it" is not an answer. You need a named person with this in their job description and time for it in the calendar.

Order of magnitude: a fraction of a full-time role with a few dozen sellers, a separate role inside finance operations with a few hundred sellers and several currencies. In a well-automated setup, that person's work comes down to exceptions.

Vendors quote automatic matching at around 90 percent of items in a tuned setup. That figure comes from their demo data rather than from yours, so treat it as a claim to verify after go-live.

And a rule we did not invent, but a standard of internal control: the person who reconciles cannot also initiate transfers or post corrections on their own. Reconciliation is the only place where both an honest mistake and a fraud come to light, and a control exercised by the person who performs the operation is not a control.

In practice: two roles, a preparer and an approver. In a small team, the finance director approves, and that is fine as long as it leaves a trace.

What decides how much reconciliation your marketplace needs?

1. The money flow model decides what you reconcile at all

If the payment provider splits the funds on its side and pays sellers directly, you mostly reconcile commissions. If you collect everything into your own account, reconciliation stops being a convenience and becomes an obligation that follows from holding other people's money ("How Do Marketplace Payments Work?" and "When You Need a Payment License to Run a Marketplace?").

2. Reconciliation and the ledger are two different guards

Internal control of the book catches a lost entry, a wrong amount, a double posting. Reconciliation catches errors at the boundary: money that never arrived, or arrived in a different amount.

Neither replaces the other, and most companies have only the first one ("Marketplace Ledger: Why Balances Must Match the Transfer").

3. Refunds and chargebacks generate most of the class three discrepancies

They come in as deductions outside the cycle and often outside the platform ("Marketplace Refunds: Who Pays for Them and Out of What?" and "Marketplace Chargebacks: Who Carries the Cost, and What if the Seller's Balance Is Empty?").

4. This is an integration requirement before it is an accounting one

A payment reference on the order, automatic ingestion of provider reports and bank statements, and a write-back once a transfer has actually gone out. All three are cheap at the start and very expensive to bolt onto a running system.

A history you never recorded cannot be reconstructed.

How do you check payment reconciliation with a vendor? 6 questions

Six questions for the vendor. Ask to be shown on screen rather than told.

1. "Show me today's list of unmatched items with the age, the reason, and the owner." If the answer is an export to a spreadsheet, you are getting a report rather than a process.
2. "Where do you get the payment provider report and the bank statement from? Automatically, or does somebody upload a file?" Manual uploading works and is common, but then a daily cadence is fiction.
3. "Is the payment reference stored on the order, and can you search in both directions?" Without it, matching is not difficult. It is impossible.
4. "What does the system do with our €40 difference?" You want to hear: it goes into the exception queue with a class and an owner. You do not want to hear: it evens out the balance.
5. "Does the paid out status change after confirmation from the bank, or after the instruction is sent?"
6. "What is the tolerance for automatic matching, and who sets it?"

Three questions for yourself, and they matter more than those six. Who by name will do this, and how many hours a week do they have for it in the calendar?

Who approves the reconciliation, and is that genuinely a different person from the one who releases payouts? After how many days does an unidentified item reach somebody who can decide to write it off?

If you do not have an answer to any of them before launch, you will get it in the third month, under worse circumstances.

Which mistakes do operators make about marketplace payment reconciliation?

1. Reconciliation once a month

The most common and the most expensive. A monthly cadence turns dozens of cheap phone calls into one expensive investigation, run in exactly the week when the finance team has the least time.

2. No payment reference on the order

The cheapest mistake to make and practically impossible to repair after the fact. Without a shared identifier, no matching can be automated at all.

3. Treating provider fees as discrepancies

A fee is a cost, and it belongs in the books. Thrown into the exception queue, it clogs it with noise and teaches the team that the queue does not need to be read.

4. Reconciling against the provider's dashboard instead of the bank statement

The dashboard shows a declaration, the statement shows a fact. The "credit ≠ sum of the lines" class is visible only from the statement.

The provider's dashboard will never reveal it.

5. One person reconciles, posts the correction, and releases the payout

Convenient in a team of three and indefensible at the first audit or the first fraud.

What do you still have to settle yourself about payment reconciliation?

This guide does not tell you how to post the difference in your own books. Which account carries the provider's fees, when you record an exchange rate difference, after how long and on what basis you may write off an unidentified amount, what evidence of a reconciliation you keep and for how long: all of that depends on your accounting policy and on the rules in your country.

Confirm it with your accounting team and with an auditor before you fix the rules in the system.

This guide also does not settle whether you are allowed to hold unidentified funds in your own account and what customer fund safeguarding duties follow from that. That is a question for a lawyer and the subject of "When You Need a Payment License to Run a Marketplace?".

It also does not say what to do when a reconciliation reveals a negative seller balance ("Marketplace Chargebacks: Who Carries the Cost, and What if the Seller's Balance Is Empty?").

The construction of the book itself is the subject of "Marketplace Ledger: Why Balances Must Match the Transfer". This one answers a single narrower question: how you know that the money your system shows is really there.

Summary: How do you know the money is really there?

Reconcile the two boundaries every day, review the exception queue every week with an owner, an age, and a next step on every item, and close the month against the books. A discrepancy from two days ago is a phone call, and the same one after eight weeks is archaeology.

Ask a vendor to show you today's unmatched items on screen. Talk to a marketplace expert if you want the six questions sharpened before the demo.

Frequently asked questions on marketplace payment reconciliation

What is marketplace payment reconciliation?

Marketplace payment reconciliation is the process of matching what the platform recorded against what the payment provider reported, what the bank actually paid, and what accounting will report. Each of the four is right within its own scope, which is why the difference between them belongs to none of them and none of them raises it.

How often should a marketplace reconcile payments?

Daily for the two boundaries, weekly for the exception queue, and monthly against the books. A monthly-only cadence turns dozens of cheap phone calls into one expensive investigation, run in exactly the week the finance team has the least time.

Who should reconcile marketplace payments?

A named person who does not also initiate transfers or post corrections. Reconciliation is the one place where both an honest mistake and a fraud surface, so it needs a preparer and an approver.

In a small team, the finance director approving is enough, as long as it leaves a trace.