{"schema":"https://ver.cy/schemas/card/1.0.0","id":"vr.wm-eco-008","code":"wm-eco-008-invoice-commercial-document","url":"https://ver.cy/models/wm-eco-008-invoice-commercial-document/","name":"Invoice / Commercial Document","alternateNames":["N1"],"kind":"world-model","status":"published","version":"0.3.0-research.1","language":"en","classifiers":{"family":"World Models","category":"Society, people and institutions","entryKind":"aggregate","plane":"","domain":["SOC.ECO.INV"],"industry":["Cross-industry"],"navPath":"NAV.SOC.ECO.INV","tags":["invoice","commercial","document","soc.eco.inv"],"facets":{}},"whatItIs":"This model covers the commercial billing document as an aggregate: its identity and type, the parties and commercial content it asserts, its tax and monetary computation, the documents it references, its lifecycle and authenticity, and the exchange, retention and governance controls that make it legally usable. It is deliberately narrower than the legacy N1 'Document & Record' entry: generic recordkeeping mechanics are delegated to the record model, and the financial consequences of the document (payment, posting, tax return) are delegated to sibling models. Storage format and access interface are projections: UBL XML, UN/CEFACT CII, hybrid PDF/A-3, JSON, Markdown, Git, MCP or MongoDB carry the same semantics.","purpose":"Provide one format-neutral context structure for commercial billing documents (invoice, credit note, debit note, self-billed invoice and their corrections) so an agent can understand, create, validate, exchange, prove and retain them across jurisdictions and syntaxes.","scope":{"in":["Billing document family and function: invoice, credit note, debit note, self-billed invoice and self-billed credit note, corrective and cancelling documents, simplified invoices, summary/periodic invoices, proforma invoices, and the document-type and profile codes that distinguish them.","Document identity and numbering, including issuer-scoped sequential numbers and tax-authority clearance identifiers where a clearance regime applies.","Party roles carried on the document (seller, buyer, payee, seller tax representative, deliver-to party) as references to externally governed party records.","Commercial content: invoice lines, item identification and classification, quantities and unit codes, prices, document- and line-level allowances and charges, invoicing period.","Tax treatment and monetary computation: tax category and rate breakdown, exemption reasons, reverse charge, document and tax-accounting currency, totals, rounding and arithmetic consistency.","Payment instruction data carried on the document: payment means, terms, due date, payee account and remittance reference (not the payment event itself).","References to order, contract, despatch advice, receiving advice, tender/lot, project, preceding invoices and supporting attachments.","Lifecycle and status of the document, buyer response, dispute, correction and cancellation.","Authenticity of origin, integrity of content and legibility: business controls and reliable audit trail, electronic signature or seal, cryptographic fixity, tax-authority clearance and registration.","Regulatory conformance evidence: mandatory particulars, national usage specifications, validation results against schema and business rules.","Exchange semantics: syntax binding and semantic fidelity, routing identifiers, envelope and delivery evidence.","Retention, storage, legibility over the storage period, legal holds and disposition, including the tension with personal-data erasure.","Ownership, role-scoped access projections and provenance/audit trail."],"out":["Payment execution, settlement, clearing, reconciliation state and remittance advice processing (delegated to WM-ECO-009 Payment / Settlement).","Order placement, contract formation and negotiation of commercial terms (delegated to the order and contract models).","Physical or digital fulfilment, despatch and goods receipt events (delegated to WM-ECO-024 Order Fulfilment).","Accounting postings, journal entries, revenue recognition and general-ledger treatment.","Periodic tax returns, digital reporting submissions (DRR), SAF-T extracts and audit-file generation; only the invoice-side data they draw on is modelled here.","Party master data and legal-entity registration; the model references party identifiers rather than governing them.","Product and service master data, catalogues and price lists.","Receivables financing, factoring, assignment, dunning and collections.","Point-of-sale fiscal receipts and cash-register fiscalisation devices.","Generic recordkeeping mechanics (rendition management, custody transfer, disposition machinery) beyond invoice-specific obligations; these belong to the document-and-record model.","Operation of exchange networks (service metadata publishing, transport certificates, access-point onboarding)."],"boundaries":[{"neighbor":"WM-ECO-009 Payment / Settlement","distinction":"The invoice carries a payment instruction (means, terms, due date, amount due) as an assertion at issue time; it does not carry settlement state. Whether the invoice was paid, partially paid or written off is derived by reference to settlement records, never stored as a mutable field on an issued document."},{"neighbor":"WM-ECO-024 Order Fulfilment","distinction":"Despatch advice and receiving advice identifiers appear on the invoice as references supporting three-way matching, and the actual delivery date is a tax-relevant business term on the invoice; the fulfilment events themselves and their exceptions are governed by the fulfilment model."},{"neighbor":"Document & Record (legacy N1)","distinction":"This model narrows the legacy generic record entry. Version chains, renditions, custody transfer and disposition machinery are reused from the record model; what is specific here is that an issued invoice is immutable and is corrected by a new document rather than by a new version, so the generic version-chain pattern must not be applied to invoice content."},{"neighbor":"Tax return and digital reporting","distinction":"The invoice supplies data to periodic returns and to transaction-level digital reporting, and under clearance regimes the reporting act can precede delivery to the buyer; but the report is a separate governed submission with its own identity, deadline and correction rules and is not a projection of this model."},{"neighbor":"Exchange network (Peppol eDelivery and comparable four-corner frameworks)","distinction":"Participant identifiers, service metadata lookup, transport profile and envelope are referenced so that routing and delivery evidence can be attached, but network operation and transport-level acknowledgement are outside the document. Transport receipt is not business acceptance."},{"neighbor":"Order and contract","distinction":"The invoice references a purchase order, contract and tender/lot; it does not restate contractual terms. Where invoice terms contradict contract terms, the model records the discrepancy as a dispute input rather than resolving it."},{"neighbor":"Accounting ledger","distinction":"Tax amounts and totals on the invoice are the legally asserted figures; the accounting entries derived from them (including any different functional-currency amounts) belong to the ledger model and may legitimately differ in presentation without invalidating the document."}]},"distinguishingFeatures":["A billing document asserting what is owed, distinct from the payment that settles it.","Its tax and monetary computation must reconcile line by line and to the totals.","Credit notes correct invoices by new documents; an issued invoice is not edited.","Separate from the order and contract it references and from ledger postings derived from it."],"structure":{"bundles":[{"id":"bnd-identity-and-classification","name":"Document identity, typing and issuance authority","description":"What this document is, how it is uniquely and lawfully named, which functional class it belongs to, which specification it claims to follow, and who was entitled to issue it when.","layers":[{"id":"lyr-identity-and-numbering","name":"Identity, type and specification claim","description":"The identifiers, functional type codes and specification/profile claims that make a billing document addressable and interpretable.","findings":[{"id":"fnd-invoice-identity","name":"Invoice identity and number scoping","description":"An invoice is identified by a number that is unique within the issuer's namespace and, in EU law, drawn from a sequential series; the number alone is not globally unique, so identity is the pair (issuer party identifier, invoice number) qualified by document type. Where a clearance regime applies, a second, authority-assigned identifier exists and legally outranks the issuer's number.","questions":[{"text":"Within which issuer namespace and document-type scope is this invoice number guaranteed unique, and what qualifies it to global uniqueness?","id":"q-inv-id-scope","kind":"identity"},{"text":"Which system of record assigned this identifier, and does an authority-assigned clearance identifier exist that takes precedence?","id":"q-inv-id-authority","kind":"authority"},{"text":"What sequence rule governs the number series, and how are gaps, resets and per-establishment series explained?","id":"q-inv-id-sequence","kind":"constraint"},{"text":"Which internal surrogate keys exist for this document and how are they prevented from being presented as the legal invoice number?","id":"q-inv-id-surrogate","kind":"interoperability"}]},{"id":"fnd-document-type-and-function","name":"Document type, function and family membership","description":"The functional class of the document — commercial invoice, credit note, debit note, self-billed invoice, corrected invoice, proforma — expressed as a governed type code, plus its function (original, copy, duplicate). Type determines which rules apply, whether a preceding-document reference is mandatory, and whether the amounts are claims or reversals.","questions":[{"text":"Which governed type code classifies this document, and from which code list version is it drawn?","id":"q-doctype-code","kind":"classification"},{"text":"What obligations does this document type trigger that other types in the family do not?","id":"q-doctype-consequences","kind":"requirement"},{"text":"Is this document a legal invoice or a non-fiscal instrument such as a proforma or request for payment, and what marks the distinction?","id":"q-doctype-proforma","kind":"definition"},{"text":"Is this instance an original, a copy or a duplicate, and how is that status carried across syntaxes?","id":"q-doctype-copy","kind":"provenance"}]},{"id":"fnd-specification-profile-and-conformance-claim","name":"Specification identifier, profile and conformance claim","description":"An invoice instance declares which semantic specification and which business process it follows, typically as a customization identifier plus a profile identifier. A usage specification may restrict the core model, and an extension may add to it; the claim determines which validation artefacts apply and what a receiver may assume.","questions":[{"text":"Which specification identifier and process profile identifier does this instance declare?","id":"q-profile-customization","kind":"interoperability"},{"text":"Does the declared specification restrict, extend or exactly implement the core semantic model, and which elements are affected?","id":"q-profile-restriction","kind":"composition"},{"text":"What evidence supports the conformance claim, rather than the claim being asserted without proof?","id":"q-profile-conformance-evidence","kind":"evidence"},{"text":"How does a receiver signal which specifications it can accept, and what happens when the declared profile is unsupported?","id":"q-profile-negotiation","kind":"exception"}]}]},{"id":"lyr-issuance-context-and-authority","name":"Issuance context and authority","description":"When the document was issued relative to the supply, which dates carry legal weight, and who was entitled to issue it.","findings":[{"id":"fnd-issuance-and-tax-point-dates","name":"Issue date, tax point and invoicing period","description":"An invoice carries several distinct dates with different legal effect: the issue date, the tax point date on which tax becomes accountable, the actual delivery date and the invoicing period for periodic billing. These are calendar dates in the core semantic model, not instants, which creates a real tension with instant-valued system timestamps.","questions":[{"text":"Which distinct dates does this document carry, and what legal effect does each one have?","id":"q-dates-roles","kind":"temporal"},{"text":"Was the document issued within the statutory time limit measured from the chargeable event, and how is that assessed?","id":"q-dates-timeliness","kind":"constraint"},{"text":"Which time zone and calendar govern a date-only business term, and how is it reconciled with instant-valued system timestamps?","id":"q-dates-timezone","kind":"temporal"},{"text":"How are the asserted business dates distinguished from the times at which the document was received, validated and archived?","id":"q-dates-observation","kind":"provenance"}]},{"id":"fnd-issuing-authority-and-self-billing","name":"Issuing authority, self-billing and outsourced issuance","description":"The party legally obliged to issue an invoice is not always the party that produces it. Issuance may be outsourced to a service provider or performed by the customer under a self-billing arrangement; in either case the supplier remains responsible, and the arrangement must be evidenced.","questions":[{"text":"Which party bears the legal obligation to issue this invoice, and which party actually produced it?","id":"q-issuance-obliged-party","kind":"ownership"},{"text":"Where issuance is self-billed or outsourced, what agreement authorises it and how is that agreement evidenced?","id":"q-issuance-mandate","kind":"authority"},{"text":"How is a self-billed document marked on its face so that a receiver can identify it without inspecting agreements?","id":"q-issuance-marking","kind":"requirement"},{"text":"How is an issuance mandate suspended or revoked, and what happens to documents issued after revocation?","id":"q-issuance-revocation","kind":"lifecycle"}]}]}]},{"id":"bnd-parties-and-commercial-content","name":"Parties and commercial content","description":"Who the document is between and what it actually bills for: party roles and their identifiers, invoice lines, item identification, quantities, prices, allowances and charges.","layers":[{"id":"lyr-parties-and-roles","name":"Party roles and identification","description":"The roles parties occupy on a billing document and the identifier schemes that make them resolvable and routable.","findings":[{"id":"fnd-party-roles-identification-and-addresses","name":"Party roles, identifiers, addresses and establishment","description":"A billing document distinguishes seller, buyer, payee, seller tax representative and deliver-to party. Each carries several identifier kinds with different governance: tax registration identifiers, legal registration identifiers, scheme-qualified organisation identifiers and electronic addresses used for routing. Addresses matter because place of supply and establishment affect tax treatment.","questions":[{"text":"Which party roles are present on this document, and which are mandatory for its type and jurisdiction?","id":"q-party-roles-present","kind":"composition"},{"text":"Which identifier schemes qualify each party identifier, and how is a bare identifier prevented from being ambiguous?","id":"q-party-identifier-schemes","kind":"identity"},{"text":"Which address and establishment details are recorded, and how do they affect tax treatment?","id":"q-party-address-relevance","kind":"spatial"},{"text":"What electronic address is used to route the document to the buyer, and how is it distinguished from the buyer's legal identity?","id":"q-party-routing-address","kind":"interoperability"},{"text":"How are party details on an issued document reconciled with later changes in the party master record?","id":"q-party-drift","kind":"provenance"}]}]},{"id":"lyr-line-items-and-pricing","name":"Line items, item identification and pricing","description":"The billed detail: line structure, what is being identified and classified, and how price, allowance and charge combine into line amounts.","findings":[{"id":"fnd-invoice-line-structure","name":"Invoice line structure and line-level scoping","description":"An invoice line groups a billed quantity, a unit of measure, a net amount, a tax category assignment and optional line-level period and references. Lines are the unit at which matching, dispute and partial credit operate, so line identity must be stable and referenceable from other documents.","questions":[{"text":"How is an individual invoice line identified so that another document can reference exactly that line?","id":"q-line-identity","kind":"identity"},{"text":"What quantity and unit of measure does the line assert, and from which code list is the unit drawn?","id":"q-line-quantity-unit","kind":"measurement"},{"text":"How is the line net amount derived from price, quantity, allowances and charges?","id":"q-line-amount-derivation","kind":"constraint"},{"text":"What line-level period and external references does the line carry, and when are they required rather than optional?","id":"q-line-period-and-refs","kind":"relationship"}]},{"id":"fnd-item-identification-and-classification","name":"Item identification, classification and attributes","description":"A line identifies what was supplied through free-text name and description, party-scoped item identifiers, standard item identifiers from registered schemes, classification codes and item attributes. Multiple identification schemes may coexist and may disagree, so precedence and scheme qualification must be explicit.","questions":[{"text":"Which item identifiers are asserted for this line and which one is authoritative when they disagree?","id":"q-item-identifier-precedence","kind":"identity"},{"text":"Is the item name and description sufficient to satisfy the legal requirement to state the nature and extent of the supply?","id":"q-item-description-sufficiency","kind":"requirement"},{"text":"Which classification codes are attached to the item and from which classification systems and versions?","id":"q-item-classification","kind":"classification"},{"text":"What item attributes and origin information are carried, and which of them affect tax or regulatory treatment?","id":"q-item-attributes","kind":"constraint"}]},{"id":"fnd-pricing-allowances-and-charges","name":"Prices, allowances and charges","description":"Pricing on a billing document separates the item net price, an optional gross price and price discount, a base quantity, and separately itemised allowances and charges at both line and document level, each with a reason and a reason code. Allowances and charges carry their own tax category, so they are not simple arithmetic adjustments.","questions":[{"text":"On what basis is the item price expressed, including base quantity and any gross price and discount?","id":"q-price-basis","kind":"measurement"},{"text":"What reason and reason code justifies each allowance or charge, and from which code list is the code drawn?","id":"q-allowance-reason","kind":"classification"},{"text":"Which tax category and rate apply to each allowance or charge, and how does that interact with the document tax breakdown?","id":"q-allowance-tax","kind":"constraint"},{"text":"Where an allowance or charge is expressed as a percentage, what base amount is it applied to and is the resulting amount stated explicitly?","id":"q-allowance-percentage-base","kind":"validation"}]}]}]},{"id":"bnd-tax-money-and-payment-instruction","name":"Tax, monetary computation and payment instruction","description":"How the document computes and states tax, in which currencies, how totals must reconcile, and what payment instruction it carries.","layers":[{"id":"lyr-tax-treatment","name":"Tax treatment and breakdown","description":"Tax categories, rates, exemptions and special regimes asserted by the document.","findings":[{"id":"fnd-tax-breakdown-and-categories","name":"Tax breakdown, categories and exemption reasons","description":"Tax is stated as a breakdown grouped by category code and rate, each group carrying a taxable amount and a tax amount. Zero-rate, exempt, reverse-charge and out-of-scope categories require an explicit reason, ideally a governed exemption reason code, because absence of tax must be justified rather than merely observed.","questions":[{"text":"How are amounts grouped into tax breakdown entries, and what defines a distinct group?","id":"q-tax-grouping","kind":"composition"},{"text":"Where no tax or a zero rate is applied, what reason and governed reason code justify it?","id":"q-tax-exemption-reason","kind":"requirement"},{"text":"Does a reverse-charge or special regime apply, and what marking does the document carry as a result?","id":"q-tax-reverse-charge","kind":"classification"},{"text":"Is a tax representative involved, and how does that change the tax identifiers stated on the document?","id":"q-tax-representative","kind":"authority"}]}]},{"id":"lyr-currency-and-totals","name":"Currency, totals and arithmetic integrity","description":"Which currencies the document uses and how its stated totals must reconcile with its parts.","findings":[{"id":"fnd-currency-and-conversion","name":"Document currency, tax accounting currency and conversion","description":"A billing document states amounts in a single document currency, but some jurisdictions require the tax amount also to be stated in a national accounting currency. That produces two tax amounts for the same supply, with a conversion basis that must be declared rather than inferred.","questions":[{"text":"In which currency are the document amounts expressed, and from which code list is the currency code drawn?","id":"q-currency-document","kind":"identity"},{"text":"Is a separate tax accounting currency required, and what tax amount is stated in it?","id":"q-currency-tax-accounting","kind":"requirement"},{"text":"What exchange rate, rate source and rate date underpin any conversion, and is that basis stated or merely assumed?","id":"q-currency-conversion-basis","kind":"provenance"},{"text":"How many decimal places apply to amounts in each currency and how are half-values rounded?","id":"q-currency-rounding","kind":"constraint"}]},{"id":"fnd-totals-rounding-and-arithmetic-consistency","name":"Document totals, rounding and arithmetic consistency","description":"Document totals are not free-form: the sum of line net amounts, document allowances and charges, tax exclusive and inclusive totals, prepaid amount, rounding amount and amount due form a constrained arithmetic system. All fixed and calculated values must be present in the instance because a receiver may not presume an omitted value.","questions":[{"text":"Which total amounts must be stated explicitly rather than left for the receiver to compute?","id":"q-totals-set","kind":"requirement"},{"text":"How is each stated total reconciled against its constituent parts, and what tolerance is permitted?","id":"q-totals-reconciliation","kind":"validation"},{"text":"When a rounding amount is stated, what does it represent and how is it constrained?","id":"q-totals-rounding-amount","kind":"constraint"},{"text":"How does a prepaid amount interact with the amount due, and where does the evidence for the prepayment live?","id":"q-totals-prepaid","kind":"relationship"}]}]},{"id":"lyr-payment-instruction","name":"Payment instruction","description":"The instruction the document carries for how, when and to whom payment should be made — distinct from settlement itself.","findings":[{"id":"fnd-payment-means-terms-and-due-date","name":"Payment means, terms, due date and remittance reference","description":"The document carries a payment instruction: a means code, account or mandate details, textual terms, a due date and a remittance or payment reference the payer should quote. This is an assertion at issue time. Whether payment occurred, when, and in what amount is governed by the settlement model and must never be written back into the issued document.","questions":[{"text":"By what means is payment requested, and what account, card or mandate details support that means?","id":"q-payment-means","kind":"process"},{"text":"When is payment due, and how is the due date derived from the terms when only terms are stated?","id":"q-payment-due","kind":"temporal"},{"text":"What remittance or payment reference must the payer quote, and how does it enable reconciliation?","id":"q-payment-reference","kind":"relationship"},{"text":"Where is settlement state recorded, and what prevents it being stored as a mutable field on the issued document?","id":"q-payment-settlement-boundary","kind":"state"}]}]}]},{"id":"bnd-references-attachments-and-evidence","name":"References, corrections and attachments","description":"What the document points to — orders, contracts, fulfilment records, preceding invoices — and what it carries with it as supporting evidence or human-readable rendition.","layers":[{"id":"lyr-commercial-document-references","name":"Commercial and correction references","description":"Typed links from the billing document to the commercial documents that justify it and to the documents it corrects or is corrected by.","findings":[{"id":"fnd-order-contract-and-fulfilment-references","name":"Order, contract and fulfilment references for matching","description":"A billing document carries references to the purchase order, sales order, contract, tender or lot, project, despatch advice and receiving advice. These enable two-way and three-way matching and are the practical basis on which a buyer decides to accept or reject.","questions":[{"text":"Which typed commercial references does this document carry and what is each one for?","id":"q-refs-typed-set","kind":"relationship"},{"text":"What buyer-supplied reference is present for the buyer's own internal routing, and how does it differ from a commercial reference?","id":"q-refs-buyer-routing","kind":"interoperability"},{"text":"What matching is performed against these references before acceptance, and at which level does it operate?","id":"q-refs-matching","kind":"process"},{"text":"How is a dangling or unresolvable reference detected and handled?","id":"q-refs-integrity","kind":"exception"}]},{"id":"fnd-preceding-document-and-correction-chain","name":"Preceding document reference and the correction chain","description":"An issued invoice is not edited. It is amended by a further document that refers specifically and unambiguously to the original — a credit note, a debit note, a corrective invoice or a cancellation, depending on jurisdiction and type. The chain of such documents, not a version history, is the true history of the commercial claim.","questions":[{"text":"Which preceding document does this document amend, and how specifically and unambiguously is it identified?","id":"q-correction-preceding-ref","kind":"relationship"},{"text":"Which correction mechanism is lawful in the governing jurisdiction for this document type, and why was it chosen?","id":"q-correction-mechanism","kind":"decision"},{"text":"What guarantees that the corrected original remains retrievable and unmodified after correction?","id":"q-correction-immutability","kind":"constraint"},{"text":"How is the net commercial effect of a correction chain computed across all linked documents?","id":"q-correction-net-effect","kind":"measurement"}]}]},{"id":"lyr-attachments-and-renditions","name":"Attachments and human-readable renditions","description":"Supporting documents carried with or referenced by the invoice, and the human-readable form of the invoice itself.","findings":[{"id":"fnd-attachments-and-human-readable-renditions","name":"Supporting attachments and the human-readable rendition","description":"An invoice may carry supporting documents as embedded binary objects or external references, each with a media type and filename. Separately, the invoice itself often has a human-readable rendition; in hybrid formats a single PDF/A-3 file embeds the structured XML, so one file carries two representations of the same invoice and their precedence must be declared. Legibility must be maintained for the whole storage period.","questions":[{"text":"What supporting objects are attached or referenced, and is each embedded or held externally?","id":"q-attachment-inventory","kind":"composition"},{"text":"Where a hybrid carrier holds both a visual and a structured representation, which one prevails if they disagree?","id":"q-rendition-precedence","kind":"authority"},{"text":"How is legibility of the human-readable form guaranteed throughout the storage period?","id":"q-rendition-legibility","kind":"quality"},{"text":"How is the integrity of each attachment bound to the invoice that carries it?","id":"q-attachment-integrity","kind":"security"}]}]}]},{"id":"bnd-lifecycle-authenticity-and-compliance","name":"Lifecycle, authenticity and regulatory conformance","description":"How the document moves through states, how the receiver responds, what makes it trustworthy, and how its legal conformance is established and evidenced.","layers":[{"id":"lyr-lifecycle-and-response","name":"Lifecycle states and receiver response","description":"The states a billing document occupies and the responses a receiver may make.","findings":[{"id":"fnd-lifecycle-states-and-transitions","name":"Lifecycle states, transitions and immutability point","description":"A billing document passes through preparation, issue, transmission, delivery, receipt, acceptance or rejection, correction and archiving. The decisive property is that content becomes immutable at issue: subsequent change is achieved by a new document, not by editing. Under clearance regimes an authority step is inserted before the document may lawfully be delivered.","questions":[{"text":"What is the permitted state set for this document type and which transitions are legal between them?","id":"q-lifecycle-state-set","kind":"lifecycle"},{"text":"At which point does content become immutable, and what technical control enforces that?","id":"q-lifecycle-immutability","kind":"state"},{"text":"Does a clearance or registration step sit between issue and delivery, and what does that change about the state model?","id":"q-lifecycle-clearance-insertion","kind":"process"},{"text":"How is each transition recorded so that the state history can be reconstructed independently of current state?","id":"q-lifecycle-event-record","kind":"event"}]},{"id":"fnd-buyer-response-and-dispute","name":"Buyer response, rejection and dispute","description":"Business acceptance is a separate act from transport delivery. A receiver may acknowledge, accept, conditionally accept, reject or dispute a billing document, with reasons that should be coded so the issuer can act automatically. Dispute suspends the practical expectation of payment without altering the document.","questions":[{"text":"What response kinds may a receiver return, and what does each one commit the receiver to?","id":"q-response-kinds","kind":"process"},{"text":"How is a rejection or dispute reason coded so that the issuer can act on it without human reading?","id":"q-response-reason-coding","kind":"classification"},{"text":"Who within the receiving organisation is authorised to accept, reject or dispute, and how is that authority evidenced?","id":"q-response-authority","kind":"authority"},{"text":"What effect does a dispute have on the payment due date and on retention obligations?","id":"q-response-effect","kind":"state"}]},{"id":"fnd-self-billing-prepayment-and-special-processes","name":"Self-billing, prepayment and special processes","description":"UN/CEFACT CII treats traditional supplier-initiated invoices and self-billing as first-class processes; the customer raises a self-billing invoice and the supplier reconciles it, raising a dispute notice on discrepancy, corrected by a self-billing credit note. UBL SelfBilledInvoice is created by the Customer Accounting Party. Article 226(10a) requires the mention 'Self-billing'. Prepayment invoices (386) collect amounts to be subtracted from a final invoice. CII also names consolidated, consignment and factored variants. These are rare relative to 380 but are not optional footnotes in a full model.","questions":[{"text":"Is this a self-billed invoice, which agreement authorises it, and has the supplier accepted or disputed it?","id":"fnd-self-billing-prepayment-and-special-processes-q01","kind":"process"},{"text":"If this is a prepayment invoice, which final invoice will absorb the prepaid amount, or if this is a final invoice, which prepayments are deducted?","id":"fnd-self-billing-prepayment-and-special-processes-q02","kind":"relationship"},{"text":"Is the invoice consolidated, consignment (non-sale), factored or freight-charge billing, and which process rules then apply?","id":"fnd-self-billing-prepayment-and-special-processes-q03","kind":"classification"}]}]},{"id":"lyr-authenticity-and-clearance","name":"Authenticity, integrity and authority clearance","description":"The controls and authority acts that make the document trustworthy as evidence.","findings":[{"id":"fnd-authenticity-integrity-and-business-controls","name":"Authenticity of origin, integrity of content and business controls","description":"Authenticity of origin and integrity of content must be assured from issue to the end of the storage period. The law is technology-neutral: any business controls creating a reliable audit trail between the invoice and the supply are acceptable, with advanced electronic signature and EDI named as examples rather than as mandatory methods. A model that assumes signatures are required overstates the requirement.","questions":[{"text":"By which method is authenticity of origin and integrity of content assured for this document, and is that method mandatory or elective in the governing jurisdiction?","id":"q-authenticity-method","kind":"security"},{"text":"What reliable audit trail links this invoice to the underlying supply, and which documents form it?","id":"q-authenticity-audit-trail","kind":"evidence"},{"text":"Where a signature or seal is applied, what exact byte scope does it cover and what does it leave unprotected?","id":"q-authenticity-signature-scope","kind":"validation"},{"text":"How is assurance maintained for the whole storage period as algorithms and certificates age?","id":"q-authenticity-longevity","kind":"quality"}]},{"id":"fnd-tax-authority-clearance-and-registration","name":"Tax authority clearance, registration and reporting acknowledgement","description":"In continuous transaction control regimes the tax authority or its agent registers the invoice before or at the moment of issue and returns an identifier, an acknowledgement instant and often a signed code. That authority-side identifier is the master-system identifier for that jurisdiction and outranks the issuer's own number for legal purposes.","questions":[{"text":"Which clearance or reporting regime governs this document, and is registration a precondition of validity or a subsequent reporting duty?","id":"q-clearance-regime","kind":"authority"},{"text":"What identifier, acknowledgement and signed code does the authority return, and how are they bound to the document?","id":"q-clearance-identifier","kind":"identity"},{"text":"Within what deadline must registration occur, measured from which event?","id":"q-clearance-deadline","kind":"temporal"},{"text":"What happens when clearance is rejected or unavailable, and what interim status may the document hold?","id":"q-clearance-failure","kind":"exception"}]}]},{"id":"lyr-regulatory-conformance","name":"Regulatory conformance and validation evidence","description":"Which particulars the law requires, how jurisdictional variants change them, and what evidence proves the document was checked.","findings":[{"id":"fnd-mandatory-particulars-and-jurisdictional-variants","name":"Mandatory particulars and jurisdictional variants","description":"The governing law prescribes an exhaustive list of particulars a full invoice must show, with reduced sets for simplified invoices and additional wording for special regimes. National usage specifications further constrain or extend the core semantic model, and language and translation obligations may apply during storage. Conformance is therefore always jurisdiction-qualified.","questions":[{"text":"Which jurisdiction's particulars apply to this document, and what determines that jurisdiction?","id":"q-particulars-applicable-set","kind":"requirement"},{"text":"Which conditional particulars are triggered by this document's circumstances, such as exemption, reverse charge, margin scheme or self-billing?","id":"q-particulars-conditional","kind":"constraint"},{"text":"Which national or sectoral usage specification applies on top of the core model, and what does it change?","id":"q-particulars-national-specification","kind":"interoperability"},{"text":"In which language is the document issued, and what translation obligation applies for audit during the storage period?","id":"q-particulars-language","kind":"access"}]},{"id":"fnd-validation-results-and-conformance-evidence","name":"Validation results and conformance evidence","description":"Conformance is demonstrated by executing versioned validation artefacts — schema checks plus business rule sets, including rules layered by a usage specification on top of the core rules — and retaining the outcome. Passing the core rule set does not imply passing a network's additional rules, so the rule set identity must be recorded with the result.","questions":[{"text":"Which rule sets and artefact versions were executed against this document, and which were not?","id":"q-validation-rule-sets","kind":"validation"},{"text":"What was the outcome per rule, and how are fatal errors distinguished from warnings?","id":"q-validation-outcomes","kind":"quality"},{"text":"How is a document revalidated when rule sets are updated on their release cycle, and what does an old pass result mean afterwards?","id":"q-validation-drift","kind":"temporal"},{"text":"What may a receiver do with a document that fails validation, and who decides?","id":"q-validation-disposition","kind":"decision"}]}]}]},{"id":"bnd-exchange-retention-and-governance","name":"Exchange, retention and governance","description":"How the document is serialised and routed, how long it must be kept and how it is disposed of, and who owns, may access and must be able to audit it.","layers":[{"id":"lyr-transmission-and-interoperability","name":"Serialisation, routing and delivery evidence","description":"How the same invoice semantics are carried across syntaxes and networks without loss, and what evidence exists that it arrived.","findings":[{"id":"fnd-syntax-binding-and-semantic-fidelity","name":"Syntax binding and semantic fidelity across serialisations","description":"The same invoice semantics are bound to different syntaxes — a business-language XML document family, a cross-industry XML syntax, and hybrid carriers embedding one inside a rendition. Bindings are not bijective: extensions, code-list versions and structural differences make round-tripping lossy, so fidelity must be measured rather than assumed.","questions":[{"text":"Which syntax binding carries this instance, and which syntax versions and code-list versions does it depend on?","id":"q-syntax-selected","kind":"interoperability"},{"text":"What semantic loss occurs when this instance is transformed into another supported syntax?","id":"q-syntax-fidelity","kind":"quality"},{"text":"Does the instance carry extension content beyond the core semantic model, and how must a receiver treat it?","id":"q-syntax-extensions","kind":"composition"},{"text":"Are all calculated values explicitly present rather than left for the receiver to infer?","id":"q-syntax-manifest-values","kind":"constraint"}]},{"id":"fnd-routing-envelope-and-delivery-evidence","name":"Routing identifiers, envelope and delivery evidence","description":"On a four-corner network the document is addressed by participant identifier, document type identifier and process identifier, discovered through service metadata, wrapped in a message envelope and transported under a defined profile. Transport-level receipt proves delivery to an access point, not business acceptance by the buyer — conflating the two is a common and consequential error.","questions":[{"text":"Which participant, document type and process identifiers address this transmission, and from which schemes are they drawn?","id":"q-routing-identifiers","kind":"identity"},{"text":"How was the receiver's capability and endpoint discovered, and what was the state of that lookup at send time?","id":"q-routing-discovery","kind":"process"},{"text":"What envelope wraps the business document, and what does it assert that the document itself does not?","id":"q-routing-envelope","kind":"composition"},{"text":"What evidence exists that the document was delivered, and how is it distinguished from business acceptance?","id":"q-routing-delivery-evidence","kind":"evidence"}]}]},{"id":"lyr-retention-and-disposition","name":"Retention, storage and disposition","description":"How long the document and its evidence must be kept, where, in what condition, and how it is lawfully destroyed.","findings":[{"id":"fnd-retention-storage-and-disposition","name":"Retention period, storage conditions, holds and erasure conflict","description":"Both issuer and recipient must retain invoices for a period fixed by national law, keeping authenticity, integrity and legibility intact and making them accessible to authorities on request; storage location and method are otherwise flexible. Retention interacts badly with personal-data erasure rights, and a legal hold must be able to suspend disposition without altering the record.","questions":[{"text":"What retention period applies to this document, from which trigger event is it measured, and which jurisdiction sets it?","id":"q-retention-period","kind":"retention"},{"text":"What conditions must storage preserve for the whole period, and how is compliance monitored?","id":"q-retention-conditions","kind":"quality"},{"text":"How is disposition suspended by a legal hold or dispute, and how is the suspension evidenced and lifted?","id":"q-retention-hold","kind":"exception"},{"text":"How is a personal-data erasure request reconciled with a statutory retention obligation on the same document?","id":"q-retention-erasure-conflict","kind":"privacy"},{"text":"What evidence is produced when disposition is finally executed?","id":"q-retention-disposition-evidence","kind":"provenance"}]}]},{"id":"lyr-ownership-access-and-audit","name":"Ownership, access projections and provenance","description":"Who owns the record, who may see which part of it, and how every handling act is traceable.","findings":[{"id":"fnd-ownership-access-and-projections","name":"Ownership, custodianship and role-scoped projections","description":"The issuing party owns the record; a service provider, access point or archiving provider may hold and process it as custodian without acquiring ownership. Different roles need different slices — a routing party needs envelope metadata only, an auditor needs the evidentiary set, a tax authority needs the full particulars — so projections are the access mechanism, not ad hoc field hiding.","questions":[{"text":"Who owns this record, who holds it as custodian, and what does the custodian agreement permit?","id":"q-ownership-holder","kind":"ownership"},{"text":"Which role-scoped projections exist, and which elements does each include and exclude?","id":"q-access-projections","kind":"access"},{"text":"On what basis may a tax or judicial authority obtain access, and what is the response obligation?","id":"q-access-authority-request","kind":"authority"},{"text":"What secondary use of invoice content is permitted to a custodian, and what is prohibited?","id":"q-access-secondary-use","kind":"privacy"}]},{"id":"fnd-audit-trail-and-provenance","name":"Provenance and end-to-end audit trail","description":"Every act on the document — generation, transformation, signing, clearance, transmission, validation, storage, disclosure, disposition — is recorded with the acting party, the acting system and an instant, distinguishing when the act happened from when it was observed. This is what allows an agent to answer for the document years later.","questions":[{"text":"Which parties and systems handled this document and in what order?","id":"q-provenance-actor-chain","kind":"provenance"},{"text":"Which content was generated, derived or transformed rather than authored, and from what source?","id":"q-provenance-derivation","kind":"composition"},{"text":"How are event times separated from observation and ingestion times where the two differ?","id":"q-provenance-time-separation","kind":"temporal"},{"text":"How would an unauthorised change to the audit trail itself be detected?","id":"q-provenance-tamper-detection","kind":"security"}]}]}]}]},"agentConduct":{"may":["Draft an invoice from an accepted order or delivery with correct references.","Validate tax computation, totals and mandatory fields against the applicable rules.","Match invoices to orders and receipts and report discrepancies.","Exchange invoices through the agreed electronic channel."],"mustNot":["Alter an issued invoice instead of issuing a credit note or corrective document.","Approve an invoice for payment without the authorized approver.","Change supplier bank details on the strength of an email or document alone.","Issue an invoice for goods or services not delivered.","Delete invoices within the legal retention period."],"requiresHuman":["Approving payment of invoices above the delegated limit.","Resolving disputes and issuing credit notes.","Confirming changes to supplier payment details."]},"ethics":{"considerations":["Invoice fraud through fake suppliers or changed bank details causes direct losses.","Late payment of invoices hurts small suppliers most.","Invoices of sole traders and consumers contain personal data."],"affectedParties":["Suppliers and their staff","Buyers and their approvers","Tax authorities and auditors"]},"owners":{"steward":"The adopting Dimension must name a single accountable owner for the invoice record — the issuing organisation by default — and must record any custodian (service provider, access point, archiving provider) with the scope of processing permitted to it; custody never transfers ownership.","roles":[{"name":"Model steward","responsibilities":["Maintain the bundle, layer, finding and question structure and its source citations","Manage version and compatibility decisions, including breaking-change migration notes","Track code-list and validation-artefact release cycles and update pinned versions","Record unresolved boundaries, conflicts and gaps rather than silently resolving them"]},{"name":"Issuer record owner","responsibilities":["Own the issued record and remain accountable for it even where issuance is outsourced or self-billed","Maintain the number series and explain any sequence gaps","Authorise corrections, disclosures and disposition","Maintain the business controls that create the reliable audit trail to the supply"]},{"name":"Exchange service provider","responsibilities":["Route, transform and deliver documents within the scope permitted by the custodian agreement","Record transmission evidence and keep it distinct from business acceptance","Report transformation losses rather than silently dropping unmappable content","Never assert ownership of, or secondary rights over, the documents it handles"]},{"name":"Tax compliance officer","responsibilities":["Determine the governing jurisdiction, particulars profile and applicable clearance or reporting regime","Approve exemption reasons, special-regime markings and required wording","Assess issue-deadline and clearance-deadline compliance","Represent the organisation in authority access requests and audits"]},{"name":"Retention custodian","responsibilities":["Assign retention classes and compute disposition eligibility","Apply and release legal holds without altering record content","Monitor legibility, integrity and re-protection of long-lived artefacts","Execute disposition and issue disposition certificates"]},{"name":"Auditor","responsibilities":["Read the evidentiary projection including correction chain, integrity evidence and provenance","Test the reliable audit trail between invoice and supply","Verify that conformance and delivery claims are backed by retained artefacts","Report unsupported claims as findings rather than accepting assertions"]}],"masterSystems":[]},"relations":[{"target":"WM-ECO-009 Payment / Settlement","type":"references","note":"The invoice asserts a payment instruction and an amount due at issue; actual settlement, partial payment and write-off are held in the settlement model and referenced back, never written into the issued document."},{"target":"WM-ECO-024 Order Fulfilment","type":"references","note":"Despatch advice and receiving advice identifiers and the actual delivery date link the invoice to the supply it bills, forming the audit trail required to assure authenticity of origin."},{"target":"Document & Record (legacy N1 recordkeeping model)","type":"extends","note":"Reuse generic recordkeeping machinery — custody, holds, disposition, preservation of legibility — while overriding the generic version-chain pattern, because an issued invoice is immutable and is amended by a new document rather than by a new version."},{"target":"Organization / Legal Entity","type":"references","note":"Seller, buyer, payee and tax-representative roles resolve to externally governed legal-entity records; the invoice stores a snapshot plus a reference, not the master record."},{"target":"Person / Contact","type":"references","note":"Named contacts, approvers and signatories on or around the document resolve to the person model, which also carries the personal-data governance those references attract."},{"target":"Product / Item and Classification","type":"references","note":"Line items reference item records and classification schemes; the invoice carries identifiers and a descriptive snapshot rather than governing item master data."},{"target":"Order and Contract","type":"references","note":"Purchase order, sales order, contract, tender and lot references support matching and are named core elements of an electronic invoice, but contractual terms remain governed elsewhere."},{"target":"Tax Registration and Rate","type":"references","note":"Tax registration identifiers, category codes, rates and exemption reason codes are drawn from externally governed registrations and code lists rather than defined by this model."},{"target":"Identifier Scheme Registry","type":"references","note":"Party identifiers, electronic addresses and item identifiers must be scheme-qualified against registered scheme lists so that a bare identifier is never treated as globally unique."},{"target":"Currency and Unit of Measure code lists","type":"aligned","note":"Currency codes, country codes and unit-of-measure codes align to the registered code lists with explicit version pinning, since code-list versions change on a scheduled release cycle."},{"target":"European semantic model of the core elements of an electronic invoice (EN 16931 family)","type":"aligned","note":"Business terms and groups are aligned to the European core invoice semantic model as expressed through registered usage specifications and supporting artefacts; alignment is claimed, conformance only where validation evidence exists."},{"target":"Invoice syntaxes (business-language XML, cross-industry XML, hybrid carriers)","type":"aligned","note":"Serialisations are projections of the same semantics; the model aligns to each binding and records mapping fidelity rather than adopting any one syntax as its definition."},{"target":"Four-corner exchange network","type":"references","note":"Participant, document type and process identifiers, service metadata discovery, envelope and transport profile are referenced to attach routing and delivery evidence; network operation stays outside the document model."},{"target":"Attachment / Binary Object","type":"composes","note":"Supporting attachments and human-readable renditions are composed into the document aggregate with their own media types and digests, and must be brought inside the integrity scope explicitly."},{"target":"Accounting Ledger / Journal Entry","type":"references","note":"Postings derived from the invoice are referenced for traceability; presentation differences in the ledger do not invalidate the document and are not modelled here."},{"target":"WM-ECO-009 Payment / Settlement","type":"neighbor","note":"The invoice carries a payment instruction (means, terms, due date, amount due) as an assertion at issue time; it does not carry settlement state. Whether the invoice was paid, partially paid or written off is derived by reference to settlement records, never stored as a mutable field on an issued document."},{"target":"WM-ECO-024 Order Fulfilment","type":"neighbor","note":"Despatch advice and receiving advice identifiers appear on the invoice as references supporting three-way matching, and the actual delivery date is a tax-relevant business term on the invoice; the fulfilment events themselves and their exceptions are governed by the fulfilment model."},{"target":"Document & Record (legacy N1)","type":"neighbor","note":"This model narrows the legacy generic record entry. Version chains, renditions, custody transfer and disposition machinery are reused from the record model; what is specific here is that an issued invoice is immutable and is corrected by a new document rather than by a new version, so the generic version-chain pattern must not be applied to invoice content."},{"target":"Tax return and digital reporting","type":"neighbor","note":"The invoice supplies data to periodic returns and to transaction-level digital reporting, and under clearance regimes the reporting act can precede delivery to the buyer; but the report is a separate governed submission with its own identity, deadline and correction rules and is not a projection of this model."},{"target":"Exchange network (Peppol eDelivery and comparable four-corner frameworks)","type":"neighbor","note":"Participant identifiers, service metadata lookup, transport profile and envelope are referenced so that routing and delivery evidence can be attached, but network operation and transport-level acknowledgement are outside the document. Transport receipt is not business acceptance."},{"target":"Order and contract","type":"neighbor","note":"The invoice references a purchase order, contract and tender/lot; it does not restate contractual terms. Where invoice terms contradict contract terms, the model records the discrepancy as a dispute input rather than resolving it."},{"target":"Accounting ledger","type":"neighbor","note":"Tax amounts and totals on the invoice are the legally asserted figures; the accounting entries derived from them (including any different functional-currency amounts) belong to the ledger model and may legitimately differ in presentation without invalidating the document."}],"interaction":{"identity":{"applicability":"required","items":["Authoritative master-system identifier: the identifier assigned by the system of record that legally owns the document — the tax authority's clearance or registration identifier where a clearance regime applies, otherwise the issuer's invoice number qualified by the issuer's registered party identifier and the document type code.","Governed global identifier or IRI: a resolvable identifier drawn from a registered scheme, such as a scheme-qualified party identifier combined with the document type identifier, or a URN minted under a governed namespace whose scheme and version are recorded with the value.","UUID or ULID assigned by the adopting Dimension: an internal surrogate used only for correlation and storage keys, never presented as the legal invoice number and never emitted in a projection that implies legal identity.","Negative rule: a date, an issue period, a file name, a storage path or a transport message identifier is never an identifier of the document. A file name or envelope identifier may serve only as a temporary correlation hint and must be replaced on first authoritative match."]},"properties":{"applicability":"not-applicable","items":[]},"recognition":{"applicability":"optional","items":["An invoice has a unique number, issue date, seller and buyer identification, lines, tax breakdown and a payable total.","It is confused with a quotation, a pro-forma invoice, a delivery note and a payment receipt."]},"capabilities":{"applicability":"required","items":["Issue commercial document: Assemble and fix a billing document from commercial inputs, assign its identifier within the issuer's series, set the legally relevant dates and freeze content as immutable.","Compute tax breakdown and totals: Derive tax breakdown groups, document totals, rounding and amount due from lines, allowances and charges, stating every calculated value explicitly rather than leaving it to be inferred.","Validate against declared specification: Execute schema and business rule artefacts for the declared specification, including any rules a network layers on the core rule set, and retain the outcome as conformance evidence.","Register or clear with tax authority: Submit the document to a clearance or reporting authority where the jurisdiction requires it, capture the returned identifier, acknowledgement and token, and bind them to the document digest.","Transmit and route document: Discover the receiver's capability and endpoint, wrap the document in the network envelope, transmit under the agreed transport profile and retain delivery evidence.","Verify authenticity and integrity: Confirm that the document originates from the asserted issuer and that its content is unaltered, using the declared assurance method — business controls, signature or seal, or exchange controls — and record the outcome.","Match to order and receipt: Reconcile the document and its lines against referenced order and goods receipt records within declared tolerances to support an acceptance decision.","Record buyer response: Capture the receiver's business response — acknowledgement, acceptance, conditional acceptance, rejection or dispute — with coded reasons and the authorising role.","Issue correction or credit: Amend an issued document by producing a new document that refers specifically and unambiguously to it, using the mechanism lawful in the governing jurisdiction.","Render human-readable form: Produce or verify the human-readable representation of the document, including hybrid carriers, and confirm that it agrees with the structured representation and remains legible.","Apply retention and disposition: Assign the retention class, compute the earliest disposition date, honour holds and, when eligible, execute disposition with evidence.","Project role-scoped view: Produce the projection appropriate to a requesting role — routing metadata, evidentiary set, authority disclosure, minimised personal-data view — and record the disclosure.","Issue self-billed invoice: Allow the customer, under agreement, to issue an invoice in the supplier's name, including the Self-billing mention, and capture supplier acceptance or dispute.","Present payment claim: Expose payable amount, due date or terms, payment means and payee so a payment process can settle the invoice without storing the payment here."]},"hazards":{"applicability":"required","items":["Payment to a fraudster after bank details are changed.","Duplicate payment of the same invoice.","Tax penalties from wrong rates or missing fields.","Loss of legally required records."]},"interfaces":{"applicability":"required","items":["EN 16931 European e-invoicing semantic model.","OASIS UBL 2.1 Invoice and CreditNote.","Peppol BIS Billing 3.0.","ISO 4217 currency codes and ISO 13616 IBAN."]},"context":{"applicability":"required","items":["The normative spine — mandatory particulars, authenticity and integrity obligations, storage duties and the acceptance rule — is drawn from European Union law and Commission guidance. It is treated as the reference frame, not as universal law.","Retention periods are not fixed by the EU directive itself but by national law of the Member State concerned; the model therefore carries the period as jurisdiction-scoped data rather than as a constant.","The four-corner exchange framework is used as the reference exchange pattern because it is adopted by authorities in Europe and beyond, including in Asia-Pacific. Other regions use different or no network mandates, and the pattern is not assumed to be universal.","Continuous transaction control regimes exist in several jurisdictions and invert the lifecycle by inserting an authority step before delivery. The model supports this as an optional inserted state; the specific identifier formats, tokens and deadlines are jurisdiction-specific and not enumerated.","The United States has no federal invoice mandate and its exchange framework is voluntary, so tax-driven mandatory particulars and clearance semantics must not be applied there by default.","Currency, country, unit and tax-category code lists are assumed to be drawn from the internationally governed lists referenced by the European supporting-artefact registry; national extensions to those lists exist and must be pinned per instance.","Default tax-invoice content follows EU VAT Directive 2006/112/EC and EN 16931; other VAT/GST regimes need local required-mention overlays.","Peppol BIS Billing 3.0 is treated as the widely deployed European CIUS, not as a global mandate.","US 19 CFR 141.86 is the worked customs-commercial-invoice primary; other customs codes (Union Customs Code, national import invoices) are analogous, not copied.","Public-sector receive-obligation under Directive 2014/55 is European; B2B mandates under ViDA are emerging and jurisdiction-timed.","Modelling assumption (not regional): the seller sequential invoice number is authoritative inside the issuer's series; it is not a global identifier.","Modelling assumption (not regional): issued invoices are immutable commercial objects; corrections use credit notes, corrected invoices or negative-amount invoices according to the chosen process.","Modelling assumption (not regional): date-only legal fields (issue date, due date, tax point) remain calendar dates, while operational observation and ingestion times use RFC 3339 instants."]}},"sources":[{"title":"Universal Business Language Version 2.1","url":"https://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html","note":"OASIS Universal Business Language Technical Committee"},{"title":"Universal Business Language Version 2.4","url":"https://docs.oasis-open.org/ubl/UBL-2.4.html","note":"OASIS Universal Business Language Technical Committee"},{"title":"Peppol BIS Billing 3.0","url":"https://docs.peppol.eu/poacc/billing/3.0/","note":"OpenPeppol AISBL"},{"title":"Peppol BIS Billing 3.0 — UBL Invoice syntax tree","url":"https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/tree/","note":"OpenPeppol AISBL"},{"title":"Registry of supporting artefacts to implement EN 16931","url":"https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467108974/Registry+of+supporting+artefacts+to+implement+EN16931","note":"European Commission — DIGITAL Building Blocks (eInvoicing)"},{"title":"VAT — Invoicing rules","url":"https://taxation-customs.ec.europa.eu/taxation/vat/vat-businesses/invoicing_en","note":"European Commission — Directorate-General for Taxation and Customs Union"},{"title":"VAT in the Digital Age (ViDA)","url":"https://taxation-customs.ec.europa.eu/taxation/vat/vat-digital-age-vida_en","note":"European Commission — Directorate-General for Taxation and Customs Union"},{"title":"Directive 2014/55/EU on electronic invoicing in public procurement","url":"https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32014L0055","note":"European Parliament and Council of the European Union (via EUR-Lex)"},{"title":"RFC 3339 — Date and Time on the Internet: Timestamps","url":"https://www.rfc-editor.org/rfc/rfc3339","note":"Internet Engineering Task Force (IETF)"},{"title":"Council Directive 2006/112/EC on the common system of value added tax","url":"https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32006L0112","note":"Council of the European Union (via EUR-Lex)"},{"title":"Explanatory notes on VAT invoicing rules (Council Directive 2010/45/EU)","url":"https://taxation-customs.ec.europa.eu/document/download/12dc566c-9f43-49d9-a306-b706879104ba_en","note":"European Commission — Directorate-General for Taxation and Customs Union"},{"title":"Peppol eDelivery Network specifications","url":"https://docs.peppol.eu/edelivery/","note":"OpenPeppol AISBL"},{"title":"Factur-X / ZUGFeRD hybrid electronic invoice specification","url":"https://fnfe-mpe.org/factur-x/factur-x_en/","note":"FNFE-MPE (Forum National de la Facture Électronique) with FeRD"},{"title":"Nationwide E-Invoicing Framework (InvoiceNow)","url":"https://www.imda.gov.sg/how-we-can-help/nationwide-e-invoicing-framework","note":"Infocomm Media Development Authority (IMDA), Singapore"},{"title":"Universal Business Language Version 2.4","url":"https://docs.oasis-open.org/ubl/os-UBL-2.4/UBL-2.4.html","note":"OASIS"},{"title":"Peppol BIS Billing 3.0","url":"https://docs.peppol.eu/poacc/billing/3.0/bis/","note":"OpenPeppol AISBL"},{"title":"Peppol BIS Billing 3.0 UBL Invoice syntax","url":"https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/","note":"OpenPeppol AISBL"},{"title":"EN 16931 compliance","url":"https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467108950/EN+16931+compliance","note":"European Commission"},{"title":"Council Directive 2006/112/EC Article 226 - Content of invoices","url":"https://www.legislation.gov.uk/eudr/2006/112/article/226","note":"European Union"},{"title":"19 CFR 141.86 Contents of invoices and general requirements","url":"https://www.law.cornell.edu/cfr/text/19/141.86","note":"United States Government"},{"title":"UN/CEFACT Cross Industry Invoice (CII) and Cross Industry Invoicing Process BRS","url":"https://unece.org/trade/uncefact/e-invoice","note":"UNECE"},{"title":"BRS Cross Industry Invoice v2.0.5","url":"https://www.unece.org/DAM/cefact/brs/BRS_CrossIndustryInvoice_v2.0.5.pdf","note":"UNECE"}],"openQuestions":["Customs and import valuation commercial invoice as a sibling trade-document entry (19 CFR 141.86 and the Union Customs Code equivalents), including assists, itemised charges, origin, in-transit resale documents and the named responsible person — deliberately excluded from this boundary.","Receivables financing, factoring, assignment of the claim, dunning and collections: the base records this as an outright gap after an ISO 20022 trade-services fetch failed, and the accepted addition only reaches document-level marking of a factored invoice, not the financing process or assignment notice effects.","National continuous transaction control profiles (Italy SdI, India GST IRN/QR, Brazil NF-e, Mexico CFDI folio, France PDP, Peppol PINT) as jurisdiction-scoped profiles over the generic clearance finding, including identifier formats, signed codes and deadlines.","EN 16931-1:2026 semantic additions arising from the ViDA package; both providers rely on secondary reporting for these fields, so they remain a gap until the CEN text or an authoritative registry artefact is retrieved.","Records-management and digital preservation standards (ISO 15489, PREMIS, and long-term signature preservation) to firm up the delegation to the record model and the maintenance of authenticity, integrity and legibility across a multi-year storage period.","Invoice Response / business response semantics as an adjacent governed transaction, to confirm the base buyer-response finding matches the transaction actually specified rather than a generalisation of it.","The normative text of the European semantic standard for the core elements of an electronic invoice was not directly accessible (paywalled catalogue). Business term and group semantics were taken from a registered usage specification and the Commission's supporting-artefact registry, so term-level detail is second-hand relative to the standard itself.","The consolidated VAT Directive text did not render for the retrieval tool; article-level requirements are grounded in the Commission's own invoicing pages and explanatory notes rather than in quoted legislative text. Article numbers are therefore referenced descriptively rather than quoted.","Records-management and preservation standards (ISO 15489, PREMIS) were inaccessible (HTTP 403). Generic recordkeeping machinery is delegated to the sibling record model rather than restated here on unverified sources.","Receivables financing, factoring, assignment and dunning are not modelled; the ISO 20022 source did not respond.","Customs-specific elements of a commercial invoice used for import or export valuation are not modelled.","Sector-specific extensions (utilities, freight, construction, healthcare, public procurement lot structures) are acknowledged as extension points but not enumerated.","Digital reporting and audit-file submission payloads are referenced as an adjacent obligation but their structure is out of scope.","North American voluntary exchange framework details were only reachable through secondary sources and were therefore excluded from the citation base.","National continuous-transaction-control systems (Italy SdI, India GST IRN/QR, Brazil NF-e, Mexico CFDI UUID folio, France PDP, Peppol PINT) are not modelled as first-class profiles.","EN 16931-1:2026 ViDA semantic additions are reported in secondary sources; the 2026 CEN text was not retrieved as a freely readable primary, so ViDA fields are a gap.","Hybrid Factur-X/ZUGFeRD PDF/A-3 containers are projections, not fully specified here.","Invoice Response (Peppol T111) is an adjacent transaction, not expanded.","Islamic finance, GCC e-invoicing, Australia/NZ GST tax-invoice rules, and utility-specific billing are not instantiated.","Exact statutory retention periods (often 6-10 years) remain N1/tax overlays, not enumerated per jurisdiction.","UBL FreightInvoice, DebitNote and Reminder are classified but not given dedicated bundles."],"resources":{"spec":"/models/wm-eco-008-invoice-commercial-document/spec.yaml","agents":"/models/wm-eco-008-invoice-commercial-document/AGENTS.md","source":"https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-eco-008"},"provenance":{"origin":"world-models research","builtFrom":["models/wm-eco-008-invoice-commercial-document/spec.yaml","ver-cy/world-models/card-supplements/wm-eco-008-invoice-commercial-document.json"],"providers":["Claude","Grok"],"researchStatus":"reviewable-draft","generatedAt":"2026-08-25T17:54:53Z","builder":"tools/build_cards.py@1.0.0"},"completeness":{"sections":{"classifiers":"filled","whatItIs":"filled","purpose":"filled","distinguishingFeatures":"filled","structure":"filled","agentConduct":"filled","ethics":"filled","owners":"filled","relations":"filled","interaction.identity":"filled","interaction.properties":"not-applicable","interaction.recognition":"filled","interaction.capabilities":"filled","interaction.hazards":"filled","interaction.interfaces":"filled","interaction.context":"filled","sources":"filled"},"notes":{"interaction.properties":"Institutional or informational subject: no invented physical properties.","_supplement":"Sections authored in card supplement 1.0.0 by Claude (Opus 5.5) (2026-10-05, unreviewed). Written from the published specification and established practice in the field; no new sources were read. Unreviewed."},"score":1.0}}