Shopee fee reconciliation: how far does the money received fall short of the selling price?

The money Shopee pays a shop is always lower than the selling price on the order. The management question is not "are we being charged?" but how much, for what, and whether it matches down to the last dong. The only way to answer is to reconcile order by order: the shop's net revenue minus total fees must equal the escrow amount the marketplace pays.

Why does the money received differ from the selling price?

Because four layers sit between the selling price and the money received: discounts, vouchers, marketplace fees and adjustments. Each layer is borne by a different party. The shop bears only its own discounts and shop vouchers; Shopee vouchers and subsidies are funded by the marketplace, and the shop still receives that portion in full.

The fees Shopee charges include the fixed fee, the payment fee, service fees for the programs you joined, and others such as the infrastructure fee or the return fee. Rates change over time and by product category, so do not memorize numbers. Read them from each order's escrow data.

Thinking leads the way: which numbers does correct reconciliation need?

You need two numbers per order and one equation. The first number is the shop's net revenue: the selling price minus discounts and shop vouchers, multiplied by the quantity the customer keeps. The second is the escrow amount the marketplace pays. Total fees are the difference between the two.

Three principles to avoid mistakes:

• Derive fees backward from escrow, do not add up the fee columns. Shopee has many fees, some in fields few people notice, such as the shipping fee for returned goods. Adding columns misses exactly those.
• Distinguish the two escrow figures. escrow_amount is the figure before adjustment. escrow_amount_after_adjustment is the money actually received after the marketplace applies its adjustments.
• Do not use the marketplace's discounted price as the base. The order's discounted price field usually already deducts the amounts Shopee funds, so using it as the base understates fees by exactly the portion the marketplace covers.

Returned orders need special attention. When a customer returns goods, Shopee refunds the customer, takes back the voucher portion for the returned goods, and may reclaim money through an adjustment in a later period. An order sold in September can be deducted in October. Viewed by wallet month it looks like fees went up; viewed by order you can see it is an old returned order.

What are the traps when pulling the numbers through the API?

There are three traps that have produced real errors while still looking plausible:

1. Pagination in the income API. In get_income_detail, next_page is an object, and you must take next_page.cursor specifically. Pass the whole object and the API returns the first page again, so the loop adds the same page several times. Always deduplicate by order ID and stop when a new page has no new orders.
2. The time range of each call. The released income API limits the date range per call, so long periods must be split into segments.
3. The expected payout date. The expected payment time field is almost always empty, so do not use it to forecast cash flow.

Read each order's escrow through get_escrow_detail. To find out whether the money has really reached the wallet, check wallet transactions by order ID.

One more principle: zero is not the same as "unknown". An order with no escrow yet must stay blank, not 0, otherwise reconciliation will report a "match" for an order the marketplace has not paid a single dong on.

Where do AI and automation help?

The heaviest part is pulling escrow for thousands of orders and marking each one as matched or mismatched. A machine should do this on a schedule. You can build it yourself with n8n or Google Sheets calling the API through Quantri360 Partner: see Shopee with n8n and Shopee orders in Google Sheets.

Once you have a table of mismatched orders, AI is useful at the reading stage: grouping mismatched orders by cause, rewriting the reasons in language accountants understand, and drafting the list of orders to dispute. AI cannot replace the equation itself; it only speeds up the explanation.

In the Quantri360 dashboard, the Đối soát tự động (Automatic reconciliation) page checks each Shopee order against the equation net revenue minus total fees equals money received, requiring a match of exactly 0 dong. Each order has a status: matched, not delivered, awaiting marketplace settlement, awaiting return sync, or mismatched. Pending orders can be expanded for handling.

What results should you measure?

• The share of orders reconciled to 0 dong out of all orders delivered in the period.
• Total marketplace fees over net revenue, by month and by shop.
• The number of orders delivered longer ago than a period you set that still have no money received.
• The amount recovered after disputes.
• The accounting hours spent on reconciliation each month.

See how to read reconciled revenue on the channel page, the calculation conventions and plan pricing. If marketplace revenue is falling and the reason is unclear, also read Shopee revenue is falling: what to check first.

Read more: multichannel e-commerce · business reports, the overview articles for this topic.

In short

• Reconcile order by order, not by the wallet's monthly total.
• Calculate fees as net revenue minus escrow after adjustment, not by adding fee columns.
• Separate amounts funded by the marketplace from amounts the shop bears.
• Track returned orders, because Shopee may reclaim money in a later period.
• When calling the API, take the correct pagination cursor and leave orders without escrow blank, not 0.