# Marketplace Payout Reconciliation: Turning a Net Deposit Back into Gross Sales, Fees and Refunds

> Booking marketplace deposits as revenue understates sales and hides fees. How bookkeeping firms gross up each payout from its settlement report, per client.

- Source: https://parserai.co/blog/marketplace-payout-reconciliation-gross-sales-fees-refunds-bookkeeping-firm
- Published: 2026-10-12

---
An online seller's bank account shows a few round-looking deposits a month from each marketplace or payment processor. None of them is a sale. Each is what is left after the channel has taken its fees, refunded customers and held back a reserve. This post covers how a bookkeeping firm turns those net deposits back into gross sales, fees and refunds, and how to run that tie-out for every e-commerce client.

Key takeaways

- A marketplace or payment processor deposit is a net figure: gross sales minus fees, refunds, chargebacks and reserves, often plus collected sales tax. Booking the deposit as revenue understates both sales and expenses.
- The settlement report behind each payout is the source document; it is what lets a bookkeeper rebuild gross sales, every fee type and every refund for the period the payout covers.
- A clearing account per sales channel, debited with gross sales and credited with each deduction and the deposit, should return to zero for every settled payout; what remains is either an open payout or a break.
- Payout periods rarely match calendar months, so month-end needs a cutoff: sales made but not yet paid out sit in the clearing account as a receivable from the channel.
- Extracting every settlement report into one schema across channels lets a firm run the same tie-out for every e-commerce client instead of rebuilding a spreadsheet per platform.

## One deposit, a dozen transactions

The shortcut most small sellers take, and many inherited books show, is to code each channel deposit to sales. It is easy and it balances the bank. It is also wrong in two directions at once: revenue is understated by every fee the channel kept, and the expense lines for selling fees, fulfillment and advertising are understated by the same amount. Gross margin looks healthier than it is, and the client cannot see what each channel actually costs.

Behind every payout there is a settlement report. It lists the orders sold in the payout period, the shipping charged, the sales tax collected, the refunds and chargebacks, each fee type, any reserve the channel held or released, and the net amount sent to the bank. That report, not the bank line, is the source document for the bookkeeping entry. The deposit only confirms that the money arrived.

1

net deposit in the bank for each payout

11

settlement components in the example payout below

4

checks in the example tie-out

## What sits between gross sales and the deposit

The components vary by channel, and each channel names them differently, but they fall into the same families. A reconciliation has to recognize each family whatever the report calls it.

| Component | What it is | Usually booked to |
| --- | --- | --- |
| Gross sales and shipping | Order value and shipping charged to the customer | Sales and shipping income |
| Sales tax | Tax collected on orders, often remitted by the marketplace itself | Sales tax payable, or netted to zero when the channel remits it |
| Refunds and chargebacks | Money returned to customers, voluntarily or through a dispute | Sales returns and allowances, chargeback losses |
| Selling and payment fees | Referral, commission, listing, transaction and processing fees | Merchant and marketplace fees expense |
| Fulfillment and advertising | Storage, pick-and-pack, and ads the channel bills against the payout | Fulfillment expense, advertising expense |
| Reserves | Funds held back against future refunds, released later | A receivable from the channel until released |

Whether a given component belongs in revenue, contra-revenue or expense is a policy decision for each client and its tax adviser. What the reconciliation guarantees is that every component is captured and lands somewhere deliberate, instead of disappearing into a net deposit.

## Where payouts stop tying out

When the components of a settlement are booked through a clearing account, the account should return to zero once the deposit posts. When it does not, the cause is almost always one of a handful of patterns.

### Payouts that cross month end

A payout covering September 21 to October 4 contains sales from two months. Booking it all on the deposit date moves September revenue into October. The fix is to post the settlement detail by transaction date, so the clearing account carries the amount the channel owes at month end, then clears when the payout lands. This is the most common break and the easiest to explain, as long as the balance is named.

### Refunds without a matching sale

A refund in this payout can belong to an order sold three payouts ago. That is normal. A refund for an order that appears in no settlement at all is not: it may be an order from another channel refunded through the wrong account, or a duplicate refund. Matching refunds to prior sales by order number catches both, the same way [credit memos are matched to open invoices](https://parserai.co/blog/vendor-credit-memo-matching-open-invoices-accounts-payable) on the payables side.

### Reserves, facilitator tax and currency

A reserve held on one payout and released on a later one shows as a missing amount, then an unexplained extra. Sales tax that a marketplace collects and remits as facilitator inflates revenue if it is left in gross sales. And a channel paying out in another currency adds a conversion difference that belongs in its own account, not buried in fees.

_Illustrative share of payout reconciliation breaks by cause across a portfolio of e-commerce bookkeeping clients in one month. Percentages are examples, not measured data._

## A tie-out that runs across every client and channel

For one client selling on one channel, a spreadsheet handles this. For forty clients across several marketplaces, payment processors and their own online stores, the bottleneck is input. Settlement reports arrive as PDFs and CSV or spreadsheet exports, each channel with its own columns and its own names for the same fee. The approach that scales is the one used for [receipt-to-bank matching](https://parserai.co/blog/receipt-bank-transaction-matching-month-end-close-bookkeeping-firm): turn every document into the same structured fields, then let rules do the comparing.

### 1. Collect the settlement reports

For each client and channel, every settlement report whose payout period touches the month, plus the bank statements for the month and the first days of the next one. Channels that pay out daily produce many small reports; downloading the period's detail as one export and splitting it by payout is usually simpler. The post on [splitting and classifying mixed PDF batches](https://parserai.co/blog/document-splitting-classification-mixed-pdf-batches) covers separating a combined file before extraction.

### 2. Extract every report into one schema

Each settlement becomes a payout id, period dates, deposit date, and one numeric field per component family from the table above, with order-level refunds kept as rows so they can be matched. Mapping each channel's labels onto the same families at extraction time is what makes one set of checks work for all of them; the post on [extraction schema design](https://parserai.co/blog/extraction-schema-design-field-types-versioning) covers typing money fields and versioning the schema when a channel adds a new fee.

### 3. Run the checks

First, the components of each settlement must sum to its reported payout: if they do not, the extraction missed a line, and nothing downstream should run. Then the payout against the bank deposit, refunds against prior sales, and the clearing account balance after posting. Each result ends in one of three states: ties, timing (naming the item that will clear it), or break.

client-payout-tieout.json — example result for one payout

```
{
  "client_id": "client-0217",
  "channel": "marketplace-a",
  "payout_id": "PO-2026-09-0418",
  "period_start": "2026-09-14",
  "period_end": "2026-09-27",
  "deposit_date": "2026-09-30",
  "settlement": {
    "gross_sales": 18642.50,
    "shipping_charged": 1240.00,
    "sales_tax_collected": 1318.20,
    "sales_tax_remitted_by_channel": -1318.20,
    "refunds": -864.00,
    "chargebacks": -129.99,
    "referral_fees": -2796.38,
    "fulfillment_fees": -1902.75,
    "advertising_fees": -410.00,
    "reserve_held": -500.00,
    "reserve_released": 350.00,
    "net_payout": 13629.38
  },
  "checks": [
    {
      "check": "settlement_components_sum_to_payout",
      "computed": 13629.38,
      "reported": 13629.38,
      "status": "ties"
    },
    {
      "check": "payout_vs_bank_deposit",
      "settlement": 13629.38,
      "bank": 13629.38,
      "status": "ties"
    },
    {
      "check": "refunds_vs_prior_sales",
      "unmatched_refunds": 1,
      "amount": -129.00,
      "status": "break",
      "hint": "Refund on order 4471-B has no sale in any extracted settlement"
    },
    {
      "check": "clearing_account_after_posting",
      "balance": 150.00,
      "explained_by": "reserve_held_net",
      "status": "timing"
    }
  ],
  "open_items": 1
}
```

In this example, the settlement components sum to the payout and the payout matches the deposit, so the extraction and the bank agree. The clearing account is left with 150.00, which is the reserve held on this payout net of the one released from an earlier payout: timing, expected to clear on a later payout. One refund has no sale in any extracted settlement, and that is the item that goes to the client.

Make the clearing account the control

A clearing account per channel turns a pile of deposits into one number that should be zero, or explained by named open payouts and reserves. Review that balance for every client every month; a balance that grows quietly is the earliest sign that revenue or fees are being lost between the channel and the books.

## Keep the numbers honest

Treat extracted settlements as a draft until the checks pass. The sum-to-payout check is unusually strong here: a settlement whose extracted components add up to the exact deposit almost certainly was read correctly, because a misread line would break the total. When a channel changes its report layout, score the extraction again against a few labelled reports before trusting it; the post on [building a field-level eval set](https://parserai.co/blog/document-extraction-accuracy-field-level-eval-set) explains how. And never let a rule write off a break: a timing item should name the payout that clears it, and a reviewer should confirm that it did.

## Month-end checklist for e-commerce clients

- Collect every settlement report whose payout period touches the month, plus bank statements through the first days of the next month.
- Extract each report into one schema: payout id, period, deposit date, one field per component family, refunds as order-level rows.
- Confirm the extracted components of each settlement sum to its reported payout.
- Match each payout to its bank deposit, and each refund to a prior sale by order number.
- Post settlement detail by transaction date through a clearing account per channel.
- Keep marketplace-remitted sales tax out of revenue, and currency differences in their own account.
- Explain the clearing account balance at month end with named open payouts and reserves.

## Where extraction fits

The accounting for marketplace sales is not complicated once the detail is in hand. What makes it slow across a portfolio is getting that detail: settlement reports from different channels, in different layouts and formats, that have to become comparable rows before any rule can run. Parser turns each of those documents into structured JSON against an extraction template you define, so the month-end payout reconciliation starts from data and the team's time goes to the breaks.

Accounting BPO

## See it on your clients’ documents.

An invoice parser for accounts payable: invoices and bills arrive by upload, e-mail or API, and the fields you define are extracted and checked against your validation rules before they reach your system. In the demo we process your documents live — no slides, no fluff.

[Book a demo](https://parserai.co/demo?icp=bpo)
## FAQ

### Why does a marketplace deposit not match the sales for the period?

Because the deposit is what remains after the channel has taken its fees, issued refunds, settled chargebacks, held or released a reserve and, in many cases, kept or passed through sales tax. The payout period also usually differs from the calendar month, so a deposit can include sales from two months and leave some of the current month for the next payout.

### What is a settlement report?

It is the statement a marketplace or payment processor issues for each payout, listing the orders, refunds, fees, adjustments and reserve movements that make up the amount deposited. It is the document a bookkeeper uses to split one net deposit into gross sales and each deduction.

### Should marketplace sales be recorded gross or net of fees?

In most cases the seller records gross sales and records the channel fees as an expense, because the seller is the party selling to the customer and the fees are a cost of selling. Sales tax collected and remitted by a marketplace facilitator is usually kept out of revenue. Confirm the treatment for each client with its tax adviser.

### How do you handle a payout that covers two months?

Record sales and deductions in the month they occurred using the settlement report detail, through a clearing account for the channel. At month end, the clearing account balance is the amount the channel owes the client for activity not yet paid out, and it clears when the next payout lands.