Open table of contents
Key takeaways
- Keep the new original file and one previously validated file for comparison.
- Confirm provider, account, period, currency, payout identity, and bank amount before analysing columns.
- Separate layout changes from real business changes such as a new fee, reserve, or correction.
- Preserve unknown rows as unresolved; do not force the residual into a familiar category.
- Accept a revised template only after the totals, row meanings, signs, and bank reconciliation have been independently checked.
The symptom: a known report no longer reconstructs
A format change often appears in one of five ways:
- a required column is missing or renamed;
- a familiar amount has moved from positive to negative presentation;
- one row now contains a subtotal that was previously split;
- a new label changes the net payout but has no supporting evidence;
- opening balance, reserve, or carried amount is calculated differently.
The safest response is not to make the old template “balance somehow”. The mismatch is evidence that the source contract has changed. Until the new format is understood, the affected payout is incomplete preparation, not a bad bank match.
The comparison package
Collect enough information to distinguish file design from economic meaning.
| Evidence | Question it answers |
|---|---|
| New original payout report | What changed in the current source? |
| Last validated report | Which fields, signs, and totals were previously understood? |
| Transaction or sales export | Do the underlying business events still agree? |
| Fee, refund, dispute, or reserve evidence | Is the new row a documented economic component? |
| Provider notice or release note | Did the provider announce a new calculation or terminology? |
| Bank statement | Which net amount was actually settled? |
File names and visual similarity are weak controls. Compare the provider account, payout ID, period, currency, row population, total formulas, and bank reference.
Synthetic example: the new row must stay open
The following file and amounts are invented.
For months, Hafenmarkt Online GmbH has used payout files with five known components. Report HM-0718 arrives with one additional row named balance correction.
| Known component | Amount |
|---|---|
| Sales activity | €9,000.00 |
| Service fees | −€1,100.00 |
| Refunds | −€250.00 |
| Chargebacks | −€180.00 |
| Reserve withholding | −€57.50 |
| Expected total under the known format | €7,412.50 |
New balance correction row | −€37.50 |
| Reported and bank-paid total | €7,375.00 |
The new file is arithmetically consistent, but the €37.50 is not yet understood. It could relate to a prior balance, a fee correction, a dispute, currency conversion, or something else. Those possibilities do not have the same bookkeeping result.
The prepared case should therefore show:
- the five known components reconstructed as before;
- the new row isolated with its exact label, amount, source location, and effect on the total;
- the bank receipt matched to €7,375.00 at settlement level;
- the €37.50 marked unresolved, with no invented expense or revenue treatment;
- a question requesting the provider notice, underlying transaction, or owner explanation.
Matching the bank proves the cash amount. It does not prove what the new row means.
How to validate the new format
1. Freeze the source
Save the original download unchanged and record when and from which provider account it was obtained. Do not overwrite it with a manually corrected spreadsheet.
2. Compare structure, not just headings
Check column count, data types, sign conventions, date semantics, currency fields, identifiers, subtotals, opening and closing balances, and row-level duplication. A column with the same name can still have a different meaning.
3. Reconstruct the known population
Apply the last validated logic only to rows whose identity and meaning remain supported. This establishes the size and location of the change without extending assumptions to the unknown part.
4. Trace every new or changed row
For each changed field, record the raw label, amount, currency, related transaction or period, supporting document, and effect on payout. If the provider documentation is silent, keep the row open.
5. Reconcile three totals
Validate the transaction or sales population to the report, the report formula to its stated net payout, and the stated net payout to the bank. Passing one of the three does not compensate for failing another.
6. Approve the interpretation and then the template
The bookkeeper can validate file completeness and arithmetic. An accountant reviews material accounting or tax meaning. Only after that should the controlled template be updated for future files. Keep the previous version and an effective-from date so historical reports are not reinterpreted accidentally.
What DeinHans does with a mismatch
For a supported format, DeinHans uses a controlled template to separate known payout components and prepare the settlement. When required fields, structure, or expected calculations no longer fit, the safe outcome is a visible exception: the original file remains attached, known rows can still be reconstructed, the unexplained residual is isolated, and the bank comparison is shown.
DeinHans does not promise universal provider coverage, automatically learn every new layout, or treat a newly observed label as a validated accounting category. Template updates require evidence and review. This protects future payouts from repeating an unexamined assumption.
Responsibility boundary
| Role | Action |
|---|---|
| Owner | Supplies the original file, provider notice, account facts, and business explanation |
| DeinHans | Detects the mismatch, preserves evidence, separates supported rows, recalculates, and asks a bounded question |
| Bookkeeper | Compares versions, checks population and arithmetic, and documents the proposed interpretation |
| Accountant | Reviews material accounting or tax treatment and approves the controlled change where required |
Release checklist for the revised format
- Original new and comparison files are retained.
- Provider, account, period, currency, and payout identity are confirmed.
- Every renamed, added, removed, or sign-changed field has been reviewed.
- Transaction population, report total, and bank receipt reconcile.
- Unknown rows remain explicit rather than hidden in fees.
- The effective date and affected provider/account scope are recorded.
- The revised template is tested against more than one representative file where possible.
- Professional review is attached where the changed meaning affects accounting or tax treatment.
Until this checklist is complete, keep the payout in review. The right output is a precise, bounded exception—not a confidently balanced guess.
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