Open table of contents
Key takeaways
- Establish the legal seller, contracting customer, platform role, and payment flow before classifying rows.
- Keep order activity, issued invoices or receipts, platform fees, corrections, payout reports, and bank evidence together.
- Separate gross activity from the net settlement and from prior balances or reserves.
- Preserve different tax or product classes as distinct source groups without exposing confidential implementation details.
- Make unknown rows and role questions visible to the accountant instead of forcing a generic marketplace treatment.
The first question: what role does the platform play?
The same platform interface can sit over different legal and commercial relationships. Public bookkeeping preparation should not infer the answer from brand or payout shape.
| Possible operating model | Evidence to inspect | Why it changes the review |
|---|---|---|
| Business sells to end customer and platform facilitates | Customer terms, invoices/receipts, order data, fee agreement | Gross sales and platform service are distinct relationships |
| Platform buys or resells under its own name | Contracts, customer document, settlement statement | The counterparty and revenue evidence may differ |
| Business sells through several channels using platform payments | Channel reports, processor reports, internal sales source | Duplicates and channel completeness become central |
| Marketplace contains third-party sellers | Seller records, commission terms, payout allocations | Amounts belonging to others must not become the platform operator's activity |
This table is a question map, not legal advice. Contracts, invoicing, actual performance, and professional review determine the treatment.
The monthly source map
| Source | What it contributes | Typical control |
|---|---|---|
| Order/transaction export | Item, date, customer/channel, gross, status, currency | Unique IDs, completeness, cancellations |
| Sales invoice, receipt, or platform-issued document | Legal document and tax evidence | Seller/customer identity, period, document version |
| Fee or commission document | Platform charge and supplier evidence | Do not treat report label as invoice automatically |
| Refund/dispute file | Link to original order and correction lifecycle | Prevent detached negative revenue or cost |
| Reserve/balance report | Amounts held, released, or carried | Prevent duplicate current-period recognition |
| Payout report | Components grouped into one settlement | Recalculate gross-to-net bridge |
| Bank/cash source | Money actually received or collected | Match settlement and preserve other channels |
A stable month has both horizontal completeness—all orders for the period—and vertical traceability from each material order or grouped activity through correction, settlement, and money.
Synthetic marketplace example
The business, platform, and amounts are invented.
Werkstadt Market GmbH sells its own goods through a marketplace. Its weekly activity and payout file shows:
| Component | Amount | Preparation result |
|---|---|---|
| Completed order activity | €18,600.00 | Preserve by documented product/tax groups for review |
| Returns and refunds | −€900.00 | Link to original orders and correction evidence |
| Platform commission | −€2,100.00 | Separate charge; verify supporting document |
| Payment service fees | −€390.00 | Separate from commission |
| Reserve withheld | −€500.00 | Open settlement balance, not automatically a fee |
| Prior reserve released | +€200.00 | Carry-forward movement, not new sales by itself |
| Expected bank payout | €14,910.00 | Match to payout identity and bank |
The calculation is:
€18,600 − €900 − €2,100 − €390 − €500 + €200 = €14,910
The prepared books do not create €14,910 of sales from the bank receipt. They retain the completed order population, link refunds to original orders, keep commission and payment fees separate, carry the €500 reserve forward, and release €200 from the previous balance without duplicating sales. The bank movement then settles the payout total.
Before using the example's structure, confirm the actual seller, invoice flow, tax facts, and platform contract. A similar report can sit over a different legal model.
A reliable monthly workflow
1. Confirm business and account boundaries
List legal entities, platform accounts, storefronts, currencies, and payment channels. A trading name is not enough to identify the legal supplier or seller.
2. Freeze the transaction population
Export the complete period and retain the original file. Check unique order IDs, statuses, cancellations, time zone, and updates after cutoff. If the platform edits historical rows, keep versions and record the extraction date.
3. Connect legal documents
Identify who issues customer invoices or receipts and where fee/commission invoices appear. A settlement report can support reconciliation without satisfying every invoice-evidence requirement.
4. Reconstruct corrections and payout components
Separate refunds, chargebacks, discounts, platform-funded incentives, merchant-funded incentives, fees, reserves, currency conversion, and other adjustments. Unknown labels remain open.
5. Reconcile payouts and other money channels
Match each payout to bank using identifier, amount, currency, and value date. Separately reconcile direct bank transfers, cash, gift cards, vouchers, or external processors so activity is neither omitted nor counted twice.
6. Roll forward open balances
Reconcile opening unsettled transactions and reserves plus current activity and adjustments minus settlements to the closing balance. Every residual needs a transaction, timing reason, reserve, or exception owner.
7. Prepare professional review
Present role evidence, source population, component bridge, open balances, and material exceptions. Ask narrow questions such as: “Does the platform issue the customer invoice in our name for these orders?” rather than “How should marketplace sales be booked?”
What DeinHans prepares
For supported payout and report formats, DeinHans can keep the platform file as one controlled case, separate visible components, prepare the gross-to-net reconstruction, connect settlement to bank, and route missing facts as questions. This is especially useful when one payout contains many rows that should not be reviewed one bank transaction at a time.
The boundary is provider- and format-specific. DeinHans does not establish who the legal seller is, does not expose private tax or account mappings, and does not promise universal marketplace support. Changed formats, unsupported channels, and material role or VAT questions remain visible for bookkeeper and accountant review.
Who does what
| Role | Responsibility |
|---|---|
| Owner/platform operator | Supplies contracts, account boundaries, sales channels, original reports, and business facts |
| DeinHans | Prepares supported source routing, payout reconstruction, questions, and bank context |
| Bookkeeper | Checks population, document links, calculations, open balances, and exception completeness |
| Accountant | Reviews seller/customer role, accounting and tax treatment, approvals, and authorised downstream work |
Review-ready platform month
The month is prepared when the seller and account scope are documented, order population is complete, issued documents are available, every payout has a reproducible component bridge and bank link, non-payout channels are reconciled, balances roll forward, and unresolved role, VAT, or provider questions are explicit. That result is valuable even when professional decisions remain open because the accountant can review a known system instead of reconstructing the business from net deposits.
Sources
Sources were checked on 21 July 2026. This article provides orientation and is not tax, legal, or accounting advice.
Related resources
See how DeinHans supports this workflow
Explore the product flow without confusing automation with professional approval.
View product