cadrumo.application.invoices.self_counterparty module¶

Whether an invoice names the taxpayer running this app as its own counterparty.

An invoice records an operation between two parties. When the recorded counterparty is the filer themselves, the record does not describe a real operation in either direction: a received invoice would mean buying from oneself, an issued one selling to oneself. Neither is a transaction the tax system recognises as between parties, and both are conspicuous – the counterparty totals on Modelo 347 and Modelo 349 are informativas AEAT cross-checks against what the counterparty declared, so a self-dealing row is matched against the filer’s own return.

This lives in the application layer for the same reason issuer_establishment does: it is a fact about the TAXPAYER, not about the invoice, and Invoice is a pure domain record that does not reach into profile state.

The failure this guards is not hypothetical or operator-typo-shaped, and the mechanism has changed while the exposure has not. The reader no longer scans for the first checksum-valid Spanish tax id, and the field contract (INVOICE_FIELD_CONTRACTS) no longer asks only for “the supplier’s NIF/NIE/CIF”: both parties are asked for separately, by role, precisely because one identifier plus a caller’s assumption made the two indistinguishable.

What survives that fix is the ISSUED case, and it survives by construction rather than by defect. On an invoice the filer issued, the supplier slot legitimately holds the filer’s OWN identifier – the document is correct and the reading is correct – so any path that takes the supplier side as the counterparty records the taxpayer against themselves. The value is real, checksum-valid, and bound for an informativa AEAT reconciles against the counterparty’s own return. A probabilistic reader transposing the two roles on an ambiguous layout reaches the same place by a different route.

Scope note, stated rather than assumed: this treats a self-naming counterparty as always wrong, which holds for every operation this codebase can currently record. Autoconsumo (LIVA art. 9) is the one family where a taxpayer documents an operation directed at themselves, and it has no IvaCategory member here – the only trace is the registry-projected art. 104.Tres prorrata exclusion, which is declared “auto-derived from the IVA category” against a category that does not exist. If autoconsumo invoicing is ever modelled, THIS is the predicate that must learn about it; until then a self-naming counterparty is a misread, not a self-supply.