What a prepared month needs before a DATEV export

Define the target

Ask the accounting firm which DATEV product and process receives the data, which period and entities are included, how documents are linked, which master data is authoritative, which booking state is accepted and who resolves import errors. “DATEV export” can describe different workflows; the receiver’s requirements determine the package.

What the prepared month must contain

• Legal entity, fiscal year and period are correct.
• Account and counterparty identifiers follow the agreed master data.
• Booking and document dates are present and plausible.
• Currency and tax information have been professionally reviewed.
• Bank, payment-provider and material clearing balances reconcile.
• Document links or identifiers resolve to the intended evidence.
• Draft, held or unresolved items are excluded or explicitly listed.
• The expected receiving process, format owner and responsible reviewer are recorded.

Illustrative control sheet—not a product output promise

Choose controls appropriate to the supported target format and actual package. The figures are synthetic. They demonstrate the accountant's control logic; they do not represent a current DeinHans export screen or guarantee that these exact fields are produced. Totals can agree while individual assignments are wrong, so retain sampling and professional review.

From prepared month to a controlled receiving process

1. Complete source coverage, reconciliation, owner questions and professional review for the agreed month.
2. Freeze the reviewed population and record the remaining accepted exceptions.
3. Confirm that the deployed DeinHans path supports the receiving firm's required artefact and version.
4. If supported, generate and transfer the package through the agreed secure channel.
5. Capture accepted, rejected and warning records in the receiving process.
6. Compare counts, totals, periods and document access using controls appropriate to the actual format.
7. Return failures to the traceable source workflow; do not fix them through unexplained edits at both ends.
8. Record final acceptance and the exact package that was accepted.

Example: one rejected row

The booking totals balance, but one row is rejected because its account identifier is unavailable in the receiving master data. Do not delete the row just to make the import succeed. Put it on the exception list, confirm the intended account with the reviewer, correct the source proposal, regenerate the export and repeat the control totals. The accepted package then has a reproducible relationship to the source.

What DeinHans can support

DeinHans can prepare connected evidence, proposals, review status and a controlled handoff. The exact DATEV scope and current integration behavior must be confirmed for the deployed product and accounting-firm target. An export remains a transport artifact; the responsible accountant owns import review and professional acceptance.

Until that current compatibility is independently validated, the public promise stops at a prepared, reviewable month. It does not claim guaranteed DATEV import, automatic posting, filing or compatibility with every DATEV product and firm configuration.

Important: Use current official DATEV format documentation and the receiving firm’s instructions. Do not publish or depend on client-specific account mappings, internal transformation rules or credentials.

Retain the handoff record

Keep period, entity, source snapshot, export version, parameters, control totals, exception list, transfer method, importer response, reviewer and acceptance date. If a later correction requires a new package, link it to the superseded export rather than replacing the history.

Protect the handoff boundary

Define one system or controlled workflow as the correction source during the handoff window. If the receiving firm edits rejected rows directly while the sender also changes them, the two records diverge and the next export may recreate the issue. Return exceptions with stable identifiers and apply the agreed correction once at the authoritative preparation layer.

Use an encrypted and approved transfer route, restrict access to the package and avoid sending credentials in the same channel. Remove temporary access after acceptance. The handoff can contain sensitive customer, employee and bank information even when the format itself is standard.

Regression pack

Maintain synthetic test cases for ordinary domestic invoices, credits, foreign currency, reverse charge, document references, split payments and period corrections. Run them after format, field or integration changes and compare generated output, import warnings and document access with the approved baseline.

The synthetic pack must not contain real organization-specific reference values or confidential account configurations. Its purpose is to validate transport and shared semantics; professional review of live cases remains a separate gate.