cadrumo.domain.iva.legend_derivation module¶

Deriving an IVA category from the regime mention the issuer printed.

The narrowest axis of the deterministic classifier, and the only one that needs nothing but the document. Spanish law does not leave the regime of an operation to be inferred: RD 1619/2012 art. 6.1 obliges the issuer to print a fixed mención whenever certain regimes apply, so for those cases the paper states the regime in words the regulation itself sets. Copying a printed phrase is something a reading stage may do; concluding what that phrase declares is something deterministic code may do. Neither step guesses.

Why this axis rather than the full rule table. classify_iva() already exists and is the single classifier for this domain; nothing here duplicates or competes with it. That table resolves the categories that depend on WHO the counterparty is – their tax status and residency – and customer_tax_status is a profile fact rather than a document fact, which is exactly why it cannot be derived from evidence alone. The legend axis needs neither input. It reports only what the issuer themselves declared in writing, so it never enters that table’s domain and the two cannot silently disagree.

Three outcomes, and “probably” is not one. A legend is present and consistent with the tax evidence on the page, or it contradicts that evidence, or there is nothing to derive from. No score, no ranking, no numeric confidence anywhere: those exist to let a caller pick a threshold, and there is no honest threshold between “the issuer declared this” and “the issuer did not”.

The absent outcome is the common one, and it must stay that way. The selected registry vocabulary has seven rows and exactly one declares a category, because that is the measured state of the regulation rather than an unfinished table. Most invoices legitimately derive nothing here. The pressure to close that gap with a default – treating an unstated counterparty country as domestic, or a legend-less invoice as ordinary domestic supply – is the restrictive- provision-as-default trap: it silently captures the whole population the provision does not govern. A wrong category is worse than an absent one, because an absent category asks the operator and a wrong one does not.

The exempt case cannot be derived here at all. Art. 6.1.j fixes no phrase for an exempt operation; it requires a reference to the provision granting the exemption, so an exempt invoice prints whichever article applies and no canonical string exists to match. That absence is load-bearing and is documented on resolve_regime_legends().