Legal policy set: written before needed, dormant until a context activates

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>

docs/regulatory/policies/RISK-POL-0012-e-invoicing.md

@@ -0,0 +1,55 @@
+---
+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.