Why is marketplace revenue different from the cash I receive?

Choose the question before choosing the report

How much did we sell, how much did the marketplace collect, and how much reached the bank are different questions. They can all be useful, but they should not share an unlabeled dashboard number. Define whether your report includes discounts, shipping, refunds, tax amounts, canceled orders, and transactions in different currencies.

For an operational review, you may want gross order value to understand demand. For a cash review, you need the actual payout and its settlement detail. For formal accounting treatment, use the definitions agreed with your finance professional. This article focuses on tracing records and explaining differences, not prescribing how every business should recognize revenue in its accounts.

Start from one deposit you can identify

Choose a single completed bank deposit and locate the matching payout reference in the payment or marketplace system. Record the amount, currency, payout date, and transfer reference. Work outward from that anchor rather than collecting every order from a nearby calendar day and hoping the totals match.

The payout record may contain transactions from several selling dates. It may also include a refund for an older purchase or an adjustment unrelated to a new order. Keep those entries intact. If you remove unfamiliar rows merely to make the report look cleaner, you also remove the explanation for why the cash differs from the sales total.

Build a bridge from activity to the deposit

Create a reconciliation bridge using the provider's categories. Begin with the relevant positive transaction amounts, subtract the applicable fees and refunds, and include adjustments or withheld amounts according to the report's definitions. Do not assume that every provider uses the same signs or column meanings. Read a sample carefully before automating the calculation.

Consider a hypothetical payout containing $1,200 in charges, $96 in fees, a $70 refund, and a $20 positive adjustment. Those entries net to $1,054 before any other report-specific items. The example is arithmetic, not a prediction of any marketplace's fee schedule. Its value is showing that the deposit can be perfectly explainable even when it is lower than the headline sales amount.

Consider a simplified, fictional settlement with one hundred dollars of eligible activity, ten dollars of refunds, and five dollars of fees. An eighty-five-dollar payout is explainable without inventing a missing fifteen-dollar sale. Real reports can include additional adjustments, reserves, taxes, currency conversions, or timing differences, so use the provider's actual categories rather than forcing every difference into this example. The purpose of the bridge is to account for each component and identify the remainder that still lacks evidence.

Keep the raw exported report alongside the working reconciliation. If someone later changes a category mapping, you should be able to recreate the calculation from its original input. Record any manual adjustment with a reason and reference instead of typing a convenient balancing number. A reconciliation that reaches zero through an unexplained adjustment has hidden the question rather than answered it. The final result should be understandable to a colleague who did not build the spreadsheet.

Keep three dates visible

An order date, a financial transaction date, and a payout date can fall in different reporting periods. If you group all three by the same date without acknowledging the difference, month-end reports can look inconsistent even when no money is missing. Store the original dates and their time zones where available.

Shopify's payout documentation describes pending funds, reserves, scheduled payouts, and transaction details. Those categories illustrate why a payment record may be valid before the money reaches the bank. For your own process, distinguish an expected timing difference from an unexplained discrepancy. Timing differences should have a reference and a next check, not remain indefinitely in a miscellaneous bucket.

Treat refunds and adjustments as their own events

A refund relates to an original purchase but occurs at a later moment and may affect a different payout. Preserve the original order reference, refund reference, amount, currency, and processing date. If several partial refunds exist, do not replace them with one vague refunded flag that loses the sequence.

Adjustments deserve the same discipline. A manual correction, dispute-related entry, or reserve movement should retain the provider's explanation and identifier. Do not force every adjustment into an order row if the provider does not identify it that way. A clear unallocated category awaiting review is more useful than a confident but incorrect assignment that makes the spreadsheet appear finished.

Separate currency differences from missing activity

An order currency and a payout currency may differ. If conversion is involved, record the amounts and currencies supplied by the provider rather than applying today's exchange rate to an old transaction. A number without a currency can be misleading even when every digit was copied correctly.

Review rounding at the level used by the report. Summing individually rounded figures can differ from rounding a total at the end. Small differences should still be understood and handled consistently, but they should not be mixed with missing transactions. Give the team a documented tolerance and escalation rule agreed with finance, rather than allowing each operator to write off whatever seems small.

Make exceptions specific enough to investigate

A useful exception says which payout, transaction, or order is missing a link and by how much. It should distinguish a deposit not found, a report not yet available, an unmatched refund, and an unexplained adjustment. These issues have different owners and different expected resolution times.

Keep a record of the original downloaded report and the transformation used for your working view, subject to your retention and access policies. If someone changes a mapping rule later, you should be able to explain the earlier result. Avoid storing unnecessary customer details in reconciliation files. Transaction and order identifiers often provide the connection you need without copying the full customer record into every worksheet.

Close the loop with a repeatable payout review

For each completed payout, confirm the bank amount, reconcile the provider's transaction total, and review unresolved entries. Then link the relevant activity to orders for operational analysis. This order of work prevents the team from assuming that a sales report alone proves what reached the bank.

Track the number and age of unreconciled payouts, not just the total value processed. A small recurring difference can reveal a mapping issue that will become larger with volume. A clear reconciliation process turns the question where did the money go into a set of traceable records. It also lets your sales dashboard stay useful without pretending that sales and cash are the same measure.