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>
2.2 KiB
| id | type | title | regime | status | activates_when | owner | written | cadence | clean_streak | last_checked | next_check |
|---|---|---|---|---|---|---|---|---|---|---|---|
| RISK-POL-0012 | legal-policy | E-invoicing | UStG §14 (as amended by the Wachstumschancengesetz), EN 16931, ViDA | active | the estate is a German business receiving B2B invoices — already true | risk-nexus | 2026-08-20 | instant | 0 | 2026-08-20T21:30:00Z | 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.