Skip to content
← Back to blog
marketplace settlementsArticle

Why an eBay payout differs from your order total

Suppose a retail finance employee compares an eBay payout with the store's orders. The totals differ, so they look for refunds, fees, and the transactions included in that payout. Automating marketplace settlement reconciliation can bring those records into one view, showing confirmed order links alongside amounts that still need an explanation.

Author

Syntalith

Published Updated 4 min read

Each payout brings another round of joining marketplace records with the store's order register. A difference between totals alone does not show whether a transaction is missing or the reports cover different periods. In a proposed Syntalith automation project, we connect those sources and prepare a view for reviewing a payout. Finance staff can move from the total to its supporting records without rebuilding the comparison in a spreadsheet each time.

Start with the transactions linked to the payout

In this example, the employee has selected store orders by sale date. The payout relates to a different set of transactions. A refund concerns an earlier order, fee records affect the settlement, and some recent orders fall outside the payout being reviewed. Comparing the payout with all sales in the selected period leaves a difference even when the available records explain it.

The eBay Finances documentation describes transaction identifiers, amounts, dates, and associated order identifiers. Transactions can be retrieved by payout ID or order ID and filtered by transaction type. These relationships provide a basis for connecting payout records with the store's orders where the source supplies the link.

A useful view lets the employee open the transactions associated with the payout and follow a recorded order reference into the store's system. The sale date, transaction date, and payout date remain visible, along with the period covered by each source report. Staff can see why a refund for an earlier order appears in the current review without assuming that every event from one day belongs to the same payout.

The report also retains the transaction type recorded by the platform. A refund to a buyer and a refund of a seller fee need separate labels when both appear in the data. That gives the reviewer a basis for interpreting the entries instead of guessing what a generic “refund” line means.

Keep unexplained amounts visible

After the supported links are matched, an item may remain without an order reference. The employee needs its amount, currency, and source description. Not every expense necessarily belongs to one order, so the absence of a link does not establish an incorrect charge. The team can investigate it at payout level or ask the colleague responsible for that type of fee.

The report should preserve source amounts and currencies and identify the report each entry came from. If the available data does not explain the remaining difference, that amount stays visible. Adding an assumed fee simply to make the totals agree would hide the question the team still needs to resolve.

This view supports the team's review of the settlement. Accounting entries and tax treatment are outside this scope.

Check the marketplace reports and existing integration first

If the platform's report already explains the payout, the work may be limited to using it consistently and linking its references with store order numbers. A separate connection makes sense when staff routinely download several reports, move identifiers between them, and search manually for the payout's components. Check the capabilities of your current sales system or marketplace integration before commissioning additional work.

With structured transaction and order identifiers, ordinary rules can handle matching and calculations. AI may help interpret inconsistent descriptions if staff can inspect the source text and review the interpretation. A model is not needed to add amounts or join records with matching identifiers.

The available relationships depend on the platform and the records it provides. A connection designed around eBay payout and order references needs to be assessed separately before extending it to another marketplace. Your team's existing exports are a useful starting point for establishing which links can be supported.

Define the work around a payout your team struggled to explain

The first conversation can start with a payout that sent an employee back and forth between reports. For a selected account and period, Syntalith can connect available payout transactions, fees, refunds, and store orders in a review view.

Your team identifies the reports it uses and the person who explains differences, while an administrator helps establish data access. Together, we determine which relationships are supported by the sources and which amounts must remain separate before agreeing to the work.

Talk to Syntalith about settlement reconciliation automation, starting with that example and the names of your current tools. See the Syntalith pricing page.

Reduce manual work in a defined process

Start with where work gets stuck and who has to repair it. We will compare the available improvements with implementation and operating costs.

Explore AI automation
Discuss an automation