docs(billing): record verified backfill (Stripe+Lago) + go-forward verification caveat

docs/superpowers/specs/2026-05-27-nexacloud-invoice-ledger-design.md

@@ -122,3 +122,20 @@ Income-account codes come from the COA (`nexa_coa_setup`); confirm/create at imp
 - Dry-run on nexamain reports the full backfill (counts per family, $ totals, unmatched lines)
   with zero writes; the real run creates drafts; bulk-post on approval.
 - Full suite green on odoo-trial (`FCB_EXIT=0`).
+
+## 10. Backfill status + go-forward caveat (2026-05-27)
+
+- **Backfill done + verified on nexamain.** 23 customer invoices posted + payment-reconciled
+  ($3,403.46), 1 void deleted. NexaCloud's `created_at`/`status`/`paid_at` proved
+  **unreliable** (sync-stamped today; one void marked otherwise), so invoice + payment dates
+  and paid status were verified against the **source systems**:
+  - **Stripe** (14 invoices, `in_*` ids) — real `created` / `paid_at` via the Stripe API.
+  - **Lago** (9 `NEX-*` invoices, `lago:*` ids, billed pre-Stripe) — `issuing_date` +
+    `payment_status=succeeded` via the Lago API (`billing.nexasystems.ca/api/api/v1`, key in
+    Fusion-Chat; Lago host 192.168.1.117, double-hop ssh via supabase-prod).
+  Partner names came from the NexaCloud `company` field (not the user's full_name).
+- **GO-FORWARD CAVEAT — do NOT enable the daily cron yet.** `_ingest_invoices` /
+  `_post_and_reconcile_paid` still date + gauge payment from NexaCloud's own fields, which
+  are unreliable for new invoices too. Before automating, the ledger must verify each new
+  invoice's date + paid status against Stripe (and Lago, until decommissioned) — i.e. fold
+  the verification used in this backfill into the ingest path.