v5.72.0 16 June 2026 Feature

Credit-Note Void: Kernel Guarantees for the Last Correction Instrument

Why This Matters

Every correction instrument in SpeyBooks carries a correctness guarantee enforced at the kernel, not left to application discipline. Void is the last of them and the sharpest. A credit note is the terminal VAT instrument: nothing sits above it to carry a later correction, so a void that gets the VAT wrong silently understates output VAT, the direction HMRC assesses. This release lands the kernel layer for credit-note void, so the guarantee is in place and proven before any void action is wired into the product.

Voiding a Credit Note, at the Kernel

  • A void requires a clean note. A credit note can move to the voided state only when no live allocations remain against it. Any remaining allocation blocks the void until it is de-allocated first. Enforced at the database layer: AX-CN-004 (state guard, migration 113), with invariant tests.

  • The reversal restores the VAT return, not just the ledger. The void is built as the exact opposite of the original credit note, with its rated lines preserved, so applying it returns both the ledger and the VAT return to where they stood before the note. This follows HMRC’s treatment of an erroneously issued credit note as an error correction rather than a change in consideration (VATREC13100, VATREC13132). The exact-reversal property is proven by invariant tests under AX-CN-005.

  • Every void is provable. A check runs against the live database at every deploy: every voided credit note has exactly one reversing entry, and every reversing entry belongs to exactly one voided note. Enforced: AX-CN-005 (deploy-time provenance sweep, migration 113), with invariant tests.

  • A void carries a reason. Voiding records a non-blank reason, and a reason cannot linger on a note that has not been voided. Enforced at the database layer (migration 113).

What Is, and Is Not, in This Release

This release lands the kernel layer and its proofs. The user-facing void action, the button and the API endpoint, follows in a later release. Until then no void is reachable from the application, and the deploy-time provenance sweep stands guard over the state machine in the meantime.

Operational Impact

  • Correction integrity: every instrument in the invoice-correction set now carries a kernel-enforced correctness guarantee, from invoice void and payment reversal through credit-note issue, allocation, de-allocation, and credit-note void.

  • VAT correctness: a credit-note void is built to restore the VAT return exactly, so a voided sales credit note cannot leave output VAT quietly understated.

  • Provenance: void provenance is swept on the live database at every deploy. A voided note without its reversal, or a reversal that belongs to no voided note, fails the deploy.

With this, the kernel side of the invoice-correction cluster is complete. What remains is the application layer that turns these guarantees into a void you can click.