How to reconstruct a platform payout for bookkeeping

Who this article is for

This article addresses two people at the same monthly moment:

• the business owner sees €8,200 in the bank although the platform dashboard shows €10,000 of sales;
• the bookkeeper or accountant receives a CSV or spreadsheet containing sales, taxes, fees, refunds, a chargeback, and balance movements, but no ready-made bookkeeping result.

It is about reconstructing that mixed evidence into a reviewable settlement. It is not a guide to one platform’s tax rules, a list of accounts, or a promise that every provider format is supported automatically.

What actually arrives

A platform month often produces several sources that describe different parts of the same business activity:

The difficulty is not missing arithmetic. It is that one file mixes profit-and-loss items, settlement items, tax-relevant sales groups, and balance movements. Some rows describe current-period activity. Others merely move an amount that was already recognised earlier.

Why the net bank amount is the wrong starting point

Suppose €8,200 arrives in the bank. Recording €8,200 as sales would make the bank agree, but the books would lose the €10,000 sales activity and the components that explain the €1,800 difference. Recording €10,000 as sales and then treating every other line as a fresh expense would also be unsafe: a reserve release or opening balance can represent an amount already carried in the books.

The correct control question is:

Which rows describe this period’s sales or costs, which rows settle an existing balance, and do all components reconcile exactly to the amount received?

That question is answerable only when the report remains connected to the bank movement and the relevant supporting documents.

Worked example: from payout file to prepared result

The following case is synthetic. “Nordlicht Mobility GmbH” receives payout P-204 for one weekly settlement.

Raw payout extract

The control calculation is:

€8,400 + €1,600 − €450 − €800 − €150 − €200 − €300 + €100 = €8,200

The calculation proves that the file reconciles internally. It does not yet prove the accounting treatment.

Prepared components

The key distinction is the reserve. Withholding €300 changes what the platform still owes; it is not automatically a new expense. Releasing €100 from a previously recorded reserve is not another €100 of sales. The exact accounting treatment is case-specific, but the workflow must preserve the distinction so that neither amount is duplicated.

How DeinHans prepares a recognised payout

For a supported and recognised layout, DeinHans uses a controlled template before uncertain interpretation. In public terms, the workflow is:

1. Recognise the source structure. The payout file is identified as a grouped settlement rather than an ordinary invoice or one bank receipt.
2. Separate the components. Sales groups, fees, refunds, chargebacks, and balance movements remain distinct instead of being collapsed into the net number.
3. Check the control total. The prepared components must reproduce the stated net payout.
4. Ask bounded questions. A new row label, unclear sales class, or unexplained balance movement stays visible as a question rather than becoming a silent guess.
5. Prepare review material. Each relevant component keeps the source context needed for a bookkeeping proposal and professional review.
6. Match the settlement. The net amount is connected to the corresponding bank movement, while the component breakdown remains visible.

This is the value of a template: repeated formats can be handled consistently without asking someone to rebuild the spreadsheet every month. It is not a universal provider integration. A changed or unknown layout requires validation, and an accountant still decides the professional treatment. DeinHans does not expose or publish private account or tax mappings in this article.

If you run the business

Supply the original payout file, the related sales and fee evidence, and the bank account receiving the settlement. Explain unfamiliar rows in business language: for example, “this is a reserve held for disputes” or “this refund relates to order 4711.” Do not rename a row simply to make the payout balance.

You should be able to see:

• whether all expected files for the period are present;
• which component or question remains unresolved;
• whether the payout calculation agrees to the bank;
• what will be handed to the accountant for review.

If you prepare or review the books

Review the source period, legal counterparty, sales grouping, fee evidence, corrections, and balance roll-forward. Confirm that a carried balance is represented once, not recreated whenever it appears in a payout report. Then review the prepared proposals and the settlement match using the actual facts of the business.

The accountant approves the accounting and tax treatment. The software’s reconstruction is preparation and control evidence; it is not professional sign-off, filing, or a guarantee that a downstream import will be accepted.

What a review-ready payout looks like

A payout is ready for deliberate review when:

• the original report and related evidence are retained;
• the format and reporting period are known;
• the components reproduce the stated net payout;
• sales, fees, refunds, chargebacks, and balance movements remain separately visible;
• unusual rows have an answer or an explicit unresolved question;
• the net settlement is matched to the correct bank movement;
• no reserve, opening balance, or prior-period amount has been duplicated;
• the accountant can see what was prepared, what the owner confirmed, and what still requires judgement.

That is the real bridge from platform activity to bookkeeping: not one convenient net entry, but one controlled reconstruction that keeps the evidence, the bank, and the professional decision connected.