“Sending the invoices” is not a package
The most common fallacy: you throw the collected invoices together and call that a hand-over. The firm then reconstructs the rest — assignment, account assignment, completeness.
A real package takes exactly this reconstruction off the firm. It is not “the invoices” but a defined bundle with a clear structure.
The original belongs in it, not just the view
The core component is the structured original — the XRechnung as XML, the ZUGFeRD invoice as PDF including embedded XML. A readable preview comes additionally but does not replace the original.
Whoever sends only PDFs hands over views, not documents. The firm can work with them, but the GoBD-compliant original trail then hangs by a thread.
Posting proposal and account assignment
A good package thinks ahead: a posting proposal with account and tax key, matching the chart of accounts used (SKR03 or SKR04). That is not an intrusion into the firm's authority but a draft it can confirm or adjust.
The effect: fewer queries, faster close. Proposing does not mean deciding — but it saves starting from zero.
The manifest: the underrated part
A manifest answers in advance the questions that otherwise come back as queries: which period? How many documents? Is anything open or disputed? Completeness at a glance.
Precisely this little note — “this is in it, this many, this month” — prevents the annoying back-and-forth about missing or duplicate documents.
The package list
What really belongs in it:
- The structured original (XRechnung XML / ZUGFeRD incl. XML).
- A readable preview per document.
- A posting proposal with account and tax key.
- Account assignment matching SKR03/SKR04.
- A manifest: period, count, open points.
- A traceable reference to the audit-proof archive.