tegwick
7f135f9e0f
Operator ruling: no external determination in build mode, but keep the set of legal policies for reuse when a work context needs one in place. docs/regulatory/policies/ catalogues thirteen, keyed by activation condition rather than by regime, with a retrieval table so a context pulls a slice: first real user account pulls six of them; a consumer-facing product in Germany pulls those plus accessibility. Two are already active and nobody had noticed — commercial and tax retention, and the e-invoicing receiving obligation that has been live since 2025 with no named owner in the estate. Four written in full; the rest carry their trigger now and get their text when a context approaches, which is the point. RISK-POL-0011 is the argument for the whole catalogue: accessibility cannot be retrofitted cheaply, so a policy retrieved at launch is a rebuild while one read at design time is just a constraint. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
55 lines
2.2 KiB
Markdown
55 lines
2.2 KiB
Markdown
---
|
|
id: RISK-POL-0012
|
|
type: legal-policy
|
|
title: "E-invoicing"
|
|
regime: "UStG §14 (as amended by the Wachstumschancengesetz), EN 16931, ViDA"
|
|
status: active
|
|
activates_when: "the estate is a German business receiving B2B invoices — already true"
|
|
owner: risk-nexus
|
|
written: "2026-08-20"
|
|
cadence: instant
|
|
clean_streak: 0
|
|
last_checked: "2026-08-20T21:30:00Z"
|
|
next_check: "2026-08-20T21:30:00Z"
|
|
---
|
|
|
|
# RISK-POL-0012 — e-invoicing
|
|
|
|
**Active now, on the receiving side.** Since 1 January 2025 a German business
|
|
must be **able to receive** a structured electronic invoice conforming to
|
|
EN 16931 for domestic B2B transactions. That obligation had no transition
|
|
period: the issuing obligations are phased, the receiving one was not.
|
|
|
|
Issuing obligations phase in afterwards, with thresholds by turnover. The
|
|
estate should assume it will be required to issue conformant invoices before it
|
|
notices the deadline, because the receiving obligation arrived that way.
|
|
|
|
## What it requires of systems
|
|
|
|
- An inbox that accepts a structured invoice (XRechnung, or ZUGFeRD's hybrid
|
|
PDF/A-3 carrying the XML) and does not treat it as an attachment to be
|
|
eyeballed.
|
|
- Storage of the **structured original**. A rendered PDF is not the invoice; a
|
|
human-readable copy alongside it is not sufficient by itself.
|
|
- Retention per `RISK-POL-0009` — eight years for the voucher, in the original
|
|
format it was received in.
|
|
|
|
## Where it bears on this estate
|
|
|
|
`markitect` and `binect-js` handle document flows, and `rapp-qonto`/`fin-hub`
|
|
touch payment and banking records. None of them is currently claimed to be the
|
|
receiving point for statutory invoices, and **this policy does not assign that
|
|
role** — naming the system that must satisfy this is the owning repo's
|
|
decision, not the register's.
|
|
|
|
What the register records is that the duty exists, is live, and currently has
|
|
no named owner in the estate.
|
|
|
|
## Evidence that would show this is met
|
|
|
|
A demonstrated receipt and archival of an EN 16931 invoice, retained in its
|
|
structured form, retrievable at eight years.
|
|
|
|
Not established. If a supplier sends one tomorrow, nobody here can say what
|
|
happens to it — which is a small, ordinary, entirely fixable gap, and exactly
|
|
the kind that only becomes visible when it is written down.
|