How accountants review a DeinHans booking proposal

What reaches the reviewer

A useful proposal should let the accountant answer:

• What happened in the business?
• Which original source supports it?
• Which amount, dates, counterparty, currency, and payment are relevant?
• Which facts came from the client?
• What effect is proposed?
• Why is the case routine, flagged, or blocked?
• What action can I take, and what will that action mean?

Internal model scores or hidden rule names are not a substitute for this explanation. The reviewer needs facts, evidence, proposed effects, and the reason professional attention is required.

A practical review order

1. Confirm the business event

Start with the document, sales record, payout component, contract occurrence, or other source. Check legal counterparty, amount, currency, relevant dates, and business purpose. If the case itself is unclear, line review is premature.

2. Check client-supplied facts

An owner may confirm that a purchase was for a client workshop, that two similar suppliers are different legal entities, or that a platform row represents a reserve. These are business facts. The owner should not be asked to select a formal account or decide a difficult VAT case.

3. Inspect the proposed effect

Check that the proposal is balanced, supported by the source, and compatible with the applicable accounting setup. Review counterparty, period, account effect, tax treatment, document connection, and any payment or open-item link.

4. Read the exception beside the proposal

A proposal may be visible even when a check failed or professional review is needed. That is preferable to a silent missing result, provided the reason is clear. “Foreign supplier details conflict” is useful; a bare “low confidence” label is not.

5. Approve, change, or return deliberately

Approval means the authorised reviewer accepts the prepared result within the actual workflow. A correction should preserve what changed and why. Returning a case should create a bounded next question, not a vague request for “more information.”

Synthetic example: the service changed, but the supplier did not

The example is invented. “Morgenrot Software GmbH” usually invoices €119 per month for software access. In June it issues a €1,190 invoice for an on-site training workshop.

The wrong shortcut would be: same supplier, therefore same treatment as the €119 software invoices. The correct review uses the current invoice and business facts. DeinHans can prepare the source, identify the changed pattern, connect the payment, and present a proposal. The accountant decides the final account and tax treatment.

Second example: one payout, several proposals

A recognised platform settlement contains sales, provider fees, a refund, and a reserve movement. The net bank receipt is only the settlement control. The prepared review material must preserve the separate components and their source connection.

The reviewer checks that:

• the component total equals the payout;
• the payout equals the bank movement;
• a refund is not represented both in sales evidence and again as an unrelated cost;
• a prior reserve release does not create revenue a second time;
• fee evidence and professional tax questions remain visible.

One “net payout” proposal would remove the information the accountant needs.

What DeinHans genuinely does

After blocking factual questions are resolved, DeinHans can prepare a booking proposal with inspectable lines and route it for review. The system also keeps failure or review reasons visible rather than requiring the reviewer to infer why no clean result exists. Prepared proposals can be reviewed, changed, or approved in the accountant workflow.

The limits are material:

• a proposal is not posting;
• an automated integrity check is not professional correctness;
• a client answer is not a tax decision;
• a visible “ready” state is not filing;
• no public article exposes proprietary implementation rules, prompts, thresholds, or internal review machinery;
• downstream DATEV import and posting remain separate controls and are never guaranteed here.

Responsibility split

Reviewer checklist

• The original source and business event are identifiable.
• Counterparty, amount, currency, and relevant dates agree with the evidence.
• Client answers state facts and do not masquerade as professional decisions.
• Proposed lines are balanced and understandable.
• Payment, open-item, payout, or contract context is attached where relevant.
• Exceptions explain the issue in plain language.
• No prior-period balance, refund, or payment creates the same result twice.
• Any correction preserves the reason and reviewer action.
• Approval is performed only by the authorised professional role.

The 10× improvement is not more automation around the final click. It is a better review object: source, facts, proposed effect, exception, and human decision held together.