# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-25T17:54:53Z", "synthesisSha256": "e180682a98259e37341f3e2ed9e019f6582793e090c6e4cd9f339809afb3c5a1", "providers": [ "Claude", "Grok" ] }, "metaModel": { "id": "WM-ECO-008", "registryId": "vr.wm-eco-008", "name": "Invoice / Commercial Document", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Society, people and institutions", "industry": [ "Cross-industry" ], "domain": [ "SOC.ECO.INV" ], "tags": [ "invoice", "commercial", "document", "soc.eco.inv" ], "status": "research draft" }, "canonicalUrl": "https://ver.cy/models/wm-eco-008-invoice-commercial-document/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-eco-008", "model": { "registry_id": "vr.wm-eco-008", "model_id": "WM-ECO-008", "name": "Invoice / Commercial Document", "entry_kind": "aggregate", "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_statement": "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.", "in_scope": [ "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_of_scope": [ "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)." ], "boundary_notes": [ { "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.", "source_refs": [ "SRC-003", "SRC-004", "SRC-006" ] }, { "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.", "source_refs": [ "SRC-004", "SRC-001" ] }, { "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.", "source_refs": [ "SRC-006", "SRC-010", "SRC-011" ] }, { "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.", "source_refs": [ "SRC-007", "SRC-005" ] }, { "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.", "source_refs": [ "SRC-012", "SRC-003" ] }, { "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.", "source_refs": [ "SRC-004", "SRC-001" ] }, { "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.", "source_refs": [ "SRC-006", "SRC-004" ] } ] }, "sources": [ { "id": "SRC-001", "title": "Universal Business Language Version 2.1", "organization": "OASIS Universal Business Language Technical Committee", "url": "https://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html", "version_or_date": "OASIS Standard, 4 November 2013", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T08:05:00Z", "relevance": "Defines the Invoice, CreditNote, DebitNote, SelfBilledInvoice and SelfBilledCreditNote document types and the common library (Party, Item, Price, TaxTotal, LegalMonetaryTotal, AllowanceCharge, DocumentReference) that is the dominant invoice syntax binding." }, { "id": "SRC-002", "title": "Universal Business Language Version 2.4", "organization": "OASIS Universal Business Language Technical Committee", "url": "https://docs.oasis-open.org/ubl/UBL-2.4.html", "version_or_date": "OASIS Standard, 20 June 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T08:07:00Z", "relevance": "Current UBL major-library release; documents backward-compatibility policy across minor revisions, the ID/schemeID identifier pattern, the manifest-values principle (receivers may not infer omitted values), and invoice-adjacent document types including FreightInvoice, Reminder and RemittanceAdvice." }, { "id": "SRC-003", "title": "Peppol BIS Billing 3.0", "organization": "OpenPeppol AISBL", "url": "https://docs.peppol.eu/poacc/billing/3.0/", "version_or_date": "May 2026 release", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T08:12:00Z", "relevance": "A registered Core Invoice Usage Specification of EN 16931 bound to UBL; supplies the billing profile identifier, customization identifier, supported document types, additional Peppol business rules layered on the CEN rules, and code-list bindings." }, { "id": "SRC-004", "title": "Peppol BIS Billing 3.0 — UBL Invoice syntax tree", "organization": "OpenPeppol AISBL", "url": "https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/tree/", "version_or_date": "May 2026 release", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T08:15:00Z", "relevance": "Element-by-element binding of EN 16931 business terms and groups (BT-1 invoice number, BT-2 issue date, BT-3 type code, BT-5/BT-6 currencies, BT-7 tax point date, BT-9 due date, BT-10 buyer reference, BT-13 order reference, BT-25 preceding invoice reference, BT-72 delivery date, BT-112/BT-115 totals, BG-4 seller, BG-7 buyer, BG-23 VAT breakdown, BG-25 invoice line) to UBL syntax." }, { "id": "SRC-005", "title": "Registry of supporting artefacts to implement EN 16931", "organization": "European Commission — DIGITAL Building Blocks (eInvoicing)", "url": "https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467108974/Registry+of+supporting+artefacts+to+implement+EN16931", "version_or_date": "Accessed August 2026; Schematron validation artefacts v1.3.16, EAS code list v16.0, VATEX code list v8.0, biannual spring/autumn release cycle", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T08:20:00Z", "relevance": "Normative registry of validation artefacts, code lists (ISO 4217 currency, ISO 3166 country, UNTDID 1001/4461/5305/7143, UNECE unit codes, EAS, ICD, VATEX) and registered CIUS/Extensions used to implement the European invoice semantic model." }, { "id": "SRC-006", "title": "VAT — Invoicing rules", "organization": "European Commission — Directorate-General for Taxation and Customs Union", "url": "https://taxation-customs.ec.europa.eu/taxation/vat/vat-businesses/invoicing_en", "version_or_date": "Accessed 25 August 2026", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T08:24:00Z", "relevance": "States when invoices must be issued, the content of full and simplified invoices, the equivalence of electronic and paper invoices, issuance subject to recipient acceptance, and the flexibility of storage location and method." }, { "id": "SRC-007", "title": "VAT in the Digital Age (ViDA)", "organization": "European Commission — Directorate-General for Taxation and Customs Union", "url": "https://taxation-customs.ec.europa.eu/taxation/vat/vat-digital-age-vida_en", "version_or_date": "Council Directive (EU) 2025/516, Regulation (EU) 2025/517, Implementing Regulation (EU) 2025/518; in force 14 April 2025", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T08:27:00Z", "relevance": "Establishes the move to structured e-invoicing and transaction-level digital reporting, the removal of the recipient-acceptance precondition for domestic mandates from entry into force, and the staged timeline to 1 July 2030 and convergence by 1 January 2035." }, { "id": "SRC-008", "title": "Directive 2014/55/EU on electronic invoicing in public procurement", "organization": "European Parliament and Council of the European Union (via EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32014L0055", "version_or_date": "16 April 2014, OJ L 133", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T08:31:00Z", "relevance": "Defines electronic invoice, core elements and syntax; mandates a European semantic standard; enumerates the core element set (process and invoice identifiers, invoice period, seller/buyer/payee, tax representative, contract reference, delivery details, payment instructions, allowance or charge information, line item information, totals, VAT breakdown) and the obligation on contracting authorities to receive and process compliant invoices." }, { "id": "SRC-009", "title": "RFC 3339 — Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3339", "version_or_date": "July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T08:34:00Z", "relevance": "Normative timestamp profile: full date-time with seconds, mandatory Z or numeric offset, leap-second handling, and the -00:00 convention for known UTC with unknown local offset." }, { "id": "SRC-010", "title": "Council Directive 2006/112/EC on the common system of value added tax", "organization": "Council of the European Union (via EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32006L0112", "version_or_date": "28 November 2006, as amended (consolidated text)", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T08:38:00Z", "relevance": "Title XI Chapter 3 is the legal source for the invoice as an instrument: definition of electronic invoice, documents treated as invoices and amending documents, obligation and time limit to issue, the exhaustive list of required invoice particulars including the sequential number, currency rules, recipient acceptance, authenticity of origin, integrity of content and legibility, and storage obligations." }, { "id": "SRC-011", "title": "Explanatory notes on VAT invoicing rules (Council Directive 2010/45/EU)", "organization": "European Commission — Directorate-General for Taxation and Customs Union", "url": "https://taxation-customs.ec.europa.eu/document/download/12dc566c-9f43-49d9-a306-b706879104ba_en", "version_or_date": "Published 5 October 2011 (non-binding guidance)", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T08:41:00Z", "relevance": "Interprets authenticity of origin, integrity of content and legibility: any business controls creating a reliable audit trail between invoice and supply are acceptable, with advanced electronic signature and EDI as examples rather than requirements, and legibility must persist throughout the storage period. Explicitly informal and not legally binding." }, { "id": "SRC-012", "title": "Peppol eDelivery Network specifications", "organization": "OpenPeppol AISBL", "url": "https://docs.peppol.eu/edelivery/", "version_or_date": "Specification index updated 2026-07-15; AS4 Transport Profile v2.0.3 (2024-04-22), SMP v1.4.0 and SML v1.3.0 (effective 2025-11-01), Business Message Envelope (SBDH) v2.0.2 (effective 2026-07-02), Identifier Usage Policy v4.4.0", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T08:45:00Z", "relevance": "Supplies the four-corner exchange semantics referenced by this model: participant, document-type and process identifiers, service metadata lookup, transport profile, message envelope and message-level status — the boundary between transport receipt and business acceptance." }, { "id": "SRC-013", "title": "Factur-X / ZUGFeRD hybrid electronic invoice specification", "organization": "FNFE-MPE (Forum National de la Facture Électronique) with FeRD", "url": "https://fnfe-mpe.org/factur-x/factur-x_en/", "version_or_date": "Factur-X 1.09.2 / ZUGFeRD 2.5.2, released 4 August 2026; CII syntax D22B", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T08:49:00Z", "relevance": "Defines the hybrid PDF/A-3 plus embedded UN/CEFACT CII invoice and its profiles (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED); the canonical case where one invoice has both a human-readable and a machine-readable carrier and their relationship must be governed." }, { "id": "SRC-014", "title": "Nationwide E-Invoicing Framework (InvoiceNow)", "organization": "Infocomm Media Development Authority (IMDA), Singapore", "url": "https://www.imda.gov.sg/how-we-can-help/nationwide-e-invoicing-framework", "version_or_date": "Accessed 25 August 2026", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T08:52:00Z", "relevance": "Evidence that the four-corner exchange framework and its access-point/solution-provider roles are adopted by authorities outside the EU, supporting the regional-generalisation claims and the separation of network role from document semantics." }, { "id": "SRC-015", "title": "Universal Business Language Version 2.4", "organization": "OASIS", "url": "https://docs.oasis-open.org/ubl/os-UBL-2.4/UBL-2.4.html", "version_or_date": "OASIS Standard, 20 June 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Published by the OASIS Universal Business Language TC; defines the Invoice, CreditNote, DebitNote, SelfBilledInvoice, SelfBilledCreditNote and FreightInvoice document families, the Invoice as a request for payment from the Supplier Accounting Party to the Customer Accounting Party, InvoiceLine and Item structures, and the exclusion of tax-reporting documents." }, { "id": "SRC-016", "title": "Peppol BIS Billing 3.0", "organization": "OpenPeppol AISBL", "url": "https://docs.peppol.eu/poacc/billing/3.0/bis/", "version_or_date": "May 2026 Release; CIUS of CEN/EN 16931:2017", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Published by the OpenPeppol Post-Award Coordinating Community; supplies the CIUS of EN 16931:2017, party roles (Customer/Supplier, Creditor/Debtor), billing profiles P1-P9, credit and correction processes, calculation rules including BR-CO-16, and payment means scope." }, { "id": "SRC-017", "title": "Peppol BIS Billing 3.0 UBL Invoice syntax", "organization": "OpenPeppol AISBL", "url": "https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/", "version_or_date": "May 2026 Release", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Binds the semantic model to UBL Invoice elements: CustomizationID and ProfileID defaults, cbc:ID without scheme attribute, buyer reference versus purchase order reference, allowances and charges, InvoicePeriod, tax point date, LegalMonetaryTotal and amount formatting rules." }, { "id": "SRC-018", "title": "EN 16931 compliance", "organization": "European Commission", "url": "https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467108950/EN+16931+compliance", "version_or_date": "Page updated 5 March 2026; standard EN 16931-1 semantic CORE and CIUS rules", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "European Commission Digital Building Blocks / eInvoicing page defining compliance at document, implementation and specification level, the CORE model, and the rule that a CIUS must be a subset of CORE and must not break CORE rules." }, { "id": "SRC-019", "title": "Council Directive 2006/112/EC Article 226 - Content of invoices", "organization": "European Union", "url": "https://www.legislation.gov.uk/eudr/2006/112/article/226", "version_or_date": "Directive of 28 November 2006; Article 226 content of invoices", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Official text of the VAT Directive as published on legislation.gov.uk; sets the mandatory invoice content model: sequential number based on one or more series, party names, addresses and VAT identification numbers, supply date, quantity and nature of supply, unit price exclusive of VAT, discounts, taxable amount per rate, VAT rate and amount, exemption or reverse-charge references, and the 'Self-billing' and 'Cash accounting' mentions." }, { "id": "SRC-020", "title": "19 CFR 141.86 Contents of invoices and general requirements", "organization": "United States Government", "url": "https://www.law.cornell.edu/cfr/text/19/141.86", "version_or_date": "Current 19 CFR 141.86 (origin T.D. 73-175; last cited amendment CBP Dec. 09-47)", "source_type": "legislation", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Legal Information Institute reproduction of the U.S. Customs and Border Protection regulation prescribing commercial invoice contents for import entry: port of entry; time, place and parties to the sale or shipment; merchandise description, marks and package numbers; quantities; purchase price or alternative value; kind of currency; itemized charges; rebates and bounties; country of origin; assists; English-language requirement; packing list; and the named responsible exporter employee." }, { "id": "SRC-021", "title": "UN/CEFACT Cross Industry Invoice (CII) and Cross Industry Invoicing Process BRS", "organization": "UNECE", "url": "https://unece.org/trade/uncefact/e-invoice", "version_or_date": "CII maximum dataset; BRS Cross Industry Invoice v2.00.05; Executive Guide on eInvoicing 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "UNECE UN/CEFACT entry point describing CII as a maximum dataset covering commercial, transport, customs, fiscal and banking uses, and the acknowledged CII syntax binding for EN 16931." }, { "id": "SRC-022", "title": "BRS Cross Industry Invoice v2.0.5", "organization": "UNECE", "url": "https://www.unece.org/DAM/cefact/brs/BRS_CrossIndustryInvoice_v2.0.5.pdf", "version_or_date": "Version 2.00.05, TBG approval 12 November 2008; PDF still published by UNECE", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "UN/CEFACT TBG1 business requirements specification for the cross industry invoicing process, including supplier-initiated invoicing, self-billing with supplier reconciliation and dispute notice, self-billing credit notes, and consolidated, consignment and factored invoice variants; source of UNTDID 1001 document type usage." } ], "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.", "rationale": "Every downstream operation — matching, correction, clearance, retention, dispute — resolves on document identity and type. Identity is contested in practice because a clearance regime may mint an identifier that outranks the issuer's own number, so it must be settled first.", "source_refs": [ "SRC-004", "SRC-006", "SRC-010", "SRC-003" ], "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.", "source_refs": [ "SRC-004", "SRC-003", "SRC-010" ], "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.", "source_refs": [ "SRC-004", "SRC-010", "SRC-006", "SRC-003" ], "questions": [ { "id": "q-inv-id-scope", "text": "Within which issuer namespace and document-type scope is this invoice number guaranteed unique, and what qualifies it to global uniqueness?", "kind": "identity", "answer_data": [ "Issuer party identifier with its scheme (ISO 6523 ICD or EAS)", "Invoice number as issued (BT-1)", "Document type code used as part of the uniqueness scope", "Statement of the uniqueness guarantee and its enforcing system" ] }, { "id": "q-inv-id-authority", "text": "Which system of record assigned this identifier, and does an authority-assigned clearance identifier exist that takes precedence?", "kind": "authority", "answer_data": [ "Assigning system identifier and its role (issuer ERP, service provider, tax authority)", "Clearance identifier value and scheme where applicable", "Precedence declaration naming the authoritative identifier", "Evidence link to the assignment response" ] }, { "id": "q-inv-id-sequence", "text": "What sequence rule governs the number series, and how are gaps, resets and per-establishment series explained?", "kind": "constraint", "answer_data": [ "Series prefix or key and reset policy", "Sequence rule statement (strictly sequential, per-year, per-establishment)", "Recorded gap register with reasons", "Jurisdictional basis for the sequence requirement" ] }, { "id": "q-inv-id-surrogate", "text": "Which internal surrogate keys exist for this document and how are they prevented from being presented as the legal invoice number?", "kind": "interoperability", "answer_data": [ "Surrogate key values and their type (UUID, ULID)", "Binding to the authoritative identifier", "Projection rule marking surrogates as non-legal", "Systems permitted to emit each key" ] } ], "data_elements": [ { "id": "de-invoice-number", "name": "Invoice number", "description": "The issuer-assigned identifier of the document, unique within the issuer's series.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-010" ] }, { "id": "de-issuer-party-identifier", "name": "Issuer party identifier", "description": "Registered identifier of the issuing party, with the scheme that governs it, used to scope the invoice number.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "de-authoritative-identifier", "name": "Authoritative document identifier", "description": "The identifier declared authoritative for this document, naming the assigning system and precedence basis.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "de-surrogate-key", "name": "Internal surrogate key", "description": "UUID or ULID minted by the adopting Dimension for internal correlation only.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-sequence-rule", "name": "Number series rule", "description": "Declaration of the sequence rule, reset policy and gap-explanation obligation for the number series.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-006" ] } ], "artifacts": [ { "id": "art-identity-binding-record", "name": "Identity binding record", "description": "A durable record binding the issuer party identifier, invoice number, document type, any clearance identifier and internal surrogates, with the precedence declaration and the assignment evidence.", "media_or_form": [ "structured record", "registry entry", "key-value binding in any serialisation" ], "serial": true, "identity_strategy": "Keyed by the declared authoritative identifier; issuer number plus issuer party identifier used as fallback when no clearance identifier exists.", "source_refs": [ "SRC-004", "SRC-006" ] } ], "inline_only_rationale": null }, { "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.", "source_refs": [ "SRC-004", "SRC-001", "SRC-005", "SRC-003" ], "questions": [ { "id": "q-doctype-code", "text": "Which governed type code classifies this document, and from which code list version is it drawn?", "kind": "classification", "answer_data": [ "Document type code value (BT-3)", "Code list identifier and version (UNTDID 1001 as constrained by the profile)", "Human-readable type label", "Restriction applied by the profile or usage specification" ] }, { "id": "q-doctype-consequences", "text": "What obligations does this document type trigger that other types in the family do not?", "kind": "requirement", "answer_data": [ "Type-conditional mandatory elements", "Requirement for a preceding-document reference", "Sign convention for amounts", "Rule identifiers that fire only for this type" ] }, { "id": "q-doctype-proforma", "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?", "kind": "definition", "answer_data": [ "Fiscal status flag with justification", "Type code and any national qualifier", "Statement of whether tax becomes accountable on this document", "Downstream systems permitted to consume it" ] }, { "id": "q-doctype-copy", "text": "Is this instance an original, a copy or a duplicate, and how is that status carried across syntaxes?", "kind": "provenance", "answer_data": [ "Copy indicator value", "Relationship to the original instance identifier", "Rendering obligation for the marking", "Syntax-specific carrier of the indicator" ] } ], "data_elements": [ { "id": "de-document-type-code", "name": "Document type code", "description": "Governed code classifying the functional type of the billing document.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "de-document-family-role", "name": "Family role", "description": "Whether the document asserts a claim, a reversal, an adjustment or a non-fiscal request.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-004" ] }, { "id": "de-copy-indicator", "name": "Copy indicator", "description": "Marks the instance as original, copy or duplicate.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-fiscal-status", "name": "Fiscal status", "description": "Declares whether the document has legal invoice effect in the governing jurisdiction.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-010" ] } ], "artifacts": [ { "id": "art-type-code-mapping", "name": "Document type code mapping table", "description": "Mapping between the governed type code, the family role, the type-conditional rule set and the equivalent codes in each supported syntax and national specification.", "media_or_form": [ "mapping table", "code list extract", "structured reference data" ], "serial": false, "identity_strategy": "Keyed by code list identifier plus version plus code value.", "source_refs": [ "SRC-005", "SRC-004" ] } ], "inline_only_rationale": null }, { "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.", "source_refs": [ "SRC-003", "SRC-005", "SRC-008", "SRC-004" ], "questions": [ { "id": "q-profile-customization", "text": "Which specification identifier and process profile identifier does this instance declare?", "kind": "interoperability", "answer_data": [ "Customization identifier string", "Profile identifier string", "Base semantic standard named by the claim", "Release or version of the usage specification" ] }, { "id": "q-profile-restriction", "text": "Does the declared specification restrict, extend or exactly implement the core semantic model, and which elements are affected?", "kind": "composition", "answer_data": [ "Restriction list (elements forbidden or narrowed)", "Extension list (elements added beyond the core)", "Registry entry for the usage specification", "Statement of whether core semantics are preserved" ] }, { "id": "q-profile-conformance-evidence", "text": "What evidence supports the conformance claim, rather than the claim being asserted without proof?", "kind": "evidence", "answer_data": [ "Validation artefact identifier and version applied", "Validation outcome with timestamp and executing actor", "Scope of what was tested", "Named residual non-conformances" ] }, { "id": "q-profile-negotiation", "text": "How does a receiver signal which specifications it can accept, and what happens when the declared profile is unsupported?", "kind": "exception", "answer_data": [ "Receiver capability declaration and its lookup mechanism", "Fallback or rejection policy", "Rejection reason code", "Renegotiation or resubmission path" ] } ], "data_elements": [ { "id": "de-customization-identifier", "name": "Customization identifier", "description": "Identifier of the semantic specification and usage rules the instance claims to follow.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-004" ] }, { "id": "de-profile-identifier", "name": "Profile identifier", "description": "Identifier of the business process the document participates in.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-specification-kind", "name": "Specification relationship", "description": "Whether the declared specification is a plain implementation, a restricting usage specification or an extension.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-008" ] }, { "id": "de-artefact-version", "name": "Validation artefact version", "description": "Version of the validation artefact set associated with the declared specification.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "art-conformance-claim-record", "name": "Conformance claim record", "description": "Record binding the declared customization and profile identifiers to the registry entry, the applicable validation artefact version and the evidence of the last successful validation.", "media_or_form": [ "structured record", "registry reference", "validation manifest" ], "serial": false, "identity_strategy": "Keyed by customization identifier plus artefact version; linked to the document's authoritative identifier.", "source_refs": [ "SRC-005", "SRC-003" ] } ], "inline_only_rationale": null } ] }, { "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.", "source_refs": [ "SRC-004", "SRC-006", "SRC-010", "SRC-009" ], "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.", "source_refs": [ "SRC-004", "SRC-010", "SRC-006", "SRC-009" ], "questions": [ { "id": "q-dates-roles", "text": "Which distinct dates does this document carry, and what legal effect does each one have?", "kind": "temporal", "answer_data": [ "Issue date value", "Tax point date value where it differs from the issue date", "Actual delivery or supply completion date", "Invoicing period start and end for periodic billing", "Legal effect statement per date" ] }, { "id": "q-dates-timeliness", "text": "Was the document issued within the statutory time limit measured from the chargeable event, and how is that assessed?", "kind": "constraint", "answer_data": [ "Chargeable event date", "Applicable statutory deadline rule and jurisdiction", "Assessed compliance outcome", "Justification where the deadline was missed" ] }, { "id": "q-dates-timezone", "text": "Which time zone and calendar govern a date-only business term, and how is it reconciled with instant-valued system timestamps?", "kind": "temporal", "answer_data": [ "Governing time zone or jurisdiction for date interpretation", "Date-only value as issued", "Corresponding system instant with explicit offset", "Rule preventing silent widening of a date into a timestamp" ] }, { "id": "q-dates-observation", "text": "How are the asserted business dates distinguished from the times at which the document was received, validated and archived?", "kind": "provenance", "answer_data": [ "Event time values asserted by the issuer", "Observation or ingestion instants recorded by each handling system", "Actor recorded against each observation", "Divergence flag where business and observation times are inconsistent" ] } ], "data_elements": [ { "id": "de-issue-date", "name": "Issue date", "description": "Calendar date on which the document was issued.", "value_kind": "date", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-010" ] }, { "id": "de-tax-point-date", "name": "Tax point date", "description": "Date on which tax becomes accountable, where it differs from the issue date.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-delivery-date", "name": "Actual delivery date", "description": "Date on which the supply was completed.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-invoicing-period", "name": "Invoicing period", "description": "Start and end dates of the period covered by a periodic or summary invoice.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-008" ] }, { "id": "de-ingestion-instant", "name": "Ingestion instant", "description": "RFC 3339 instant, with seconds and explicit offset, at which a handling system first observed the document.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-012" ] } ], "artifacts": [ { "id": "art-date-provenance-log", "name": "Date provenance log", "description": "Append-only log pairing each asserted business date with the observation instants, actors and systems that recorded or transformed it, used to defend timeliness assessments.", "media_or_form": [ "append-only event log", "structured record set" ], "serial": true, "identity_strategy": "Entries keyed by document authoritative identifier plus monotonically increasing sequence; never keyed by date.", "source_refs": [ "SRC-009", "SRC-011" ] } ], "inline_only_rationale": null }, { "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.", "source_refs": [ "SRC-006", "SRC-010", "SRC-001", "SRC-011" ], "questions": [ { "id": "q-issuance-obliged-party", "text": "Which party bears the legal obligation to issue this invoice, and which party actually produced it?", "kind": "ownership", "answer_data": [ "Obliged party identifier and role", "Producing party identifier and role", "Basis of the obligation in the governing jurisdiction", "Statement of retained responsibility" ] }, { "id": "q-issuance-mandate", "text": "Where issuance is self-billed or outsourced, what agreement authorises it and how is that agreement evidenced?", "kind": "authority", "answer_data": [ "Agreement identifier and effective period", "Agreement type (self-billing, outsourcing mandate, third-party issuance)", "Acceptance procedure evidence", "Scope limits of the mandate" ] }, { "id": "q-issuance-marking", "text": "How is a self-billed document marked on its face so that a receiver can identify it without inspecting agreements?", "kind": "requirement", "answer_data": [ "Self-billing marking text or code", "Document type code used", "Placement obligation across syntaxes and renditions", "Jurisdictional wording requirement" ] }, { "id": "q-issuance-revocation", "text": "How is an issuance mandate suspended or revoked, and what happens to documents issued after revocation?", "kind": "lifecycle", "answer_data": [ "Revocation instant with explicit offset", "Revoking actor and authority", "Treatment rule for documents issued after revocation", "Remediation path (cancellation, re-issuance)" ] } ], "data_elements": [ { "id": "de-obliged-party", "name": "Obliged issuing party", "description": "Reference to the party legally required to issue the document.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-010" ] }, { "id": "de-producing-party", "name": "Producing party", "description": "Reference to the party or service provider that actually generated the document.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-self-billing-indicator", "name": "Self-billing indicator", "description": "Marks the document as issued by the customer on the supplier's behalf.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-issuance-mandate-reference", "name": "Issuance mandate reference", "description": "Reference to the agreement authorising self-billing or outsourced issuance, with its effective period.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-010" ] } ], "artifacts": [ { "id": "art-issuance-mandate", "name": "Issuance mandate or self-billing agreement", "description": "The governing agreement evidencing that the producing party was authorised to issue on behalf of the obliged party, including scope, effective period and revocation record.", "media_or_form": [ "agreement document", "signed record", "structured agreement metadata" ], "serial": false, "identity_strategy": "Keyed by the agreement's own registered identifier in the contract system of record; surrogate key only if none exists.", "source_refs": [ "SRC-011", "SRC-006" ] } ], "inline_only_rationale": null } ] } ] }, { "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.", "rationale": "The core semantic model of an electronic invoice is explicitly built from seller, buyer, payee and tax-representative information plus line item, allowance/charge and delivery information; these are the assertions that carry commercial and evidential weight.", "source_refs": [ "SRC-008", "SRC-004", "SRC-001" ], "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.", "source_refs": [ "SRC-004", "SRC-005", "SRC-012" ], "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.", "source_refs": [ "SRC-004", "SRC-005", "SRC-008", "SRC-012" ], "questions": [ { "id": "q-party-roles-present", "text": "Which party roles are present on this document, and which are mandatory for its type and jurisdiction?", "kind": "composition", "answer_data": [ "Role list with party references", "Mandatory-role determination and its rule basis", "Reason a permitted role is absent", "Role-specific conditional requirements" ] }, { "id": "q-party-identifier-schemes", "text": "Which identifier schemes qualify each party identifier, and how is a bare identifier prevented from being ambiguous?", "kind": "identity", "answer_data": [ "Identifier value with scheme identifier and scheme version", "Scheme registry reference", "Distinction between tax, legal-registration and routing identifiers", "Resolution procedure for unqualified identifiers" ] }, { "id": "q-party-address-relevance", "text": "Which address and establishment details are recorded, and how do they affect tax treatment?", "kind": "spatial", "answer_data": [ "Postal address components with country code", "Country and subdivision codes with code list version", "Fixed establishment indicator", "Place-of-supply consequence statement" ] }, { "id": "q-party-routing-address", "text": "What electronic address is used to route the document to the buyer, and how is it distinguished from the buyer's legal identity?", "kind": "interoperability", "answer_data": [ "Electronic address value and its scheme code", "Scheme code list version", "Binding between routing address and legal party record", "Rule that routing address is not a legal identifier" ] }, { "id": "q-party-drift", "text": "How are party details on an issued document reconciled with later changes in the party master record?", "kind": "provenance", "answer_data": [ "Snapshot of party details as asserted at issue", "Reference to the governing party record and its version", "Divergence detection rule", "Policy forbidding retroactive overwrite of issued party details" ] } ], "data_elements": [ { "id": "de-party-role", "name": "Party role", "description": "The role a referenced party occupies on the document (seller, buyer, payee, tax representative, deliver-to).", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004", "SRC-008" ] }, { "id": "de-party-tax-identifier", "name": "Party tax registration identifier", "description": "Tax registration identifier of the party, with the jurisdiction that issued it.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "de-party-scheme-identifier", "name": "Scheme-qualified party identifier", "description": "Organisation identifier with an explicit scheme drawn from a registered scheme list.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-012" ] }, { "id": "de-party-electronic-address", "name": "Electronic address", "description": "Routing address of the party with its scheme code, used for network delivery.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-012" ] }, { "id": "de-party-postal-address", "name": "Postal address", "description": "Structured postal address with country code, used for legal identification and place-of-supply reasoning.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-party-snapshot-reference", "name": "Party record snapshot reference", "description": "Reference to the governing party record and the version observed at issue time.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "art-party-role-snapshot", "name": "Party role snapshot", "description": "Immutable capture of each party's asserted name, identifiers, address and electronic address as carried on the issued document, with a link to the governing party record version.", "media_or_form": [ "structured record", "embedded document section", "snapshot in any serialisation" ], "serial": false, "identity_strategy": "Keyed by document authoritative identifier plus role code; linked to the party's master-system identifier where one exists.", "source_refs": [ "SRC-004", "SRC-012" ] } ], "inline_only_rationale": null } ] }, { "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.", "source_refs": [ "SRC-004", "SRC-001", "SRC-005" ], "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.", "source_refs": [ "SRC-004", "SRC-001", "SRC-008" ], "questions": [ { "id": "q-line-identity", "text": "How is an individual invoice line identified so that another document can reference exactly that line?", "kind": "identity", "answer_data": [ "Line identifier value and its uniqueness scope", "Stability guarantee across corrections", "Referencing convention used by credit notes and responses", "Sub-line identification scheme where composite items are used" ] }, { "id": "q-line-quantity-unit", "text": "What quantity and unit of measure does the line assert, and from which code list is the unit drawn?", "kind": "measurement", "answer_data": [ "Invoiced quantity value", "Unit of measure code and code list version", "Base quantity used for pricing", "Rounding or precision rule applied to the quantity" ] }, { "id": "q-line-amount-derivation", "text": "How is the line net amount derived from price, quantity, allowances and charges?", "kind": "constraint", "answer_data": [ "Line net amount value", "Derivation expression and its inputs", "Applicable arithmetic rule identifiers", "Tolerance policy for rounding differences" ] }, { "id": "q-line-period-and-refs", "text": "What line-level period and external references does the line carry, and when are they required rather than optional?", "kind": "relationship", "answer_data": [ "Line invoicing period start and end", "Order line reference", "Objects such as document, receipt or contract references at line level", "Conditional requirement rules" ] } ], "data_elements": [ { "id": "de-line-identifier", "name": "Invoice line identifier", "description": "Identifier of the line, unique within the document.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-line-quantity", "name": "Invoiced quantity", "description": "Quantity billed on the line, with its unit of measure code.", "value_kind": "quantity", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "de-line-net-amount", "name": "Line net amount", "description": "Net amount of the line, exclusive of tax, after line allowances and charges.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-line-period", "name": "Line invoicing period", "description": "Period covered by the individual line where it differs from the document period.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-line-order-reference", "name": "Order line reference", "description": "Reference to the corresponding line of the purchase order.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-001" ] } ], "artifacts": [ { "id": "art-line-detail-set", "name": "Invoice line detail set", "description": "The complete ordered set of invoice lines with their identifiers, quantities, amounts, tax assignments and references, addressable as a unit for matching and partial credit.", "media_or_form": [ "structured collection", "tabular rendition", "embedded document section" ], "serial": false, "identity_strategy": "Keyed by document authoritative identifier; each member keyed by document identifier plus line identifier.", "source_refs": [ "SRC-004", "SRC-001" ] } ], "inline_only_rationale": null }, { "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.", "source_refs": [ "SRC-001", "SRC-004", "SRC-005", "SRC-002" ], "questions": [ { "id": "q-item-identifier-precedence", "text": "Which item identifiers are asserted for this line and which one is authoritative when they disagree?", "kind": "identity", "answer_data": [ "Seller, buyer, manufacturer and standard item identifiers with schemes", "Precedence rule and its owner", "Recorded disagreement between schemes", "Reconciliation action taken" ] }, { "id": "q-item-description-sufficiency", "text": "Is the item name and description sufficient to satisfy the legal requirement to state the nature and extent of the supply?", "kind": "requirement", "answer_data": [ "Item name and description text", "Assessment against the governing particulars requirement", "Language and any translation obligation", "Remediation where the description is insufficient" ] }, { "id": "q-item-classification", "text": "Which classification codes are attached to the item and from which classification systems and versions?", "kind": "classification", "answer_data": [ "Classification code values", "Classification system identifier and version", "Purpose of each classification (statistical, tax, procurement)", "Rule governing whether classification is required" ] }, { "id": "q-item-attributes", "text": "What item attributes and origin information are carried, and which of them affect tax or regulatory treatment?", "kind": "constraint", "answer_data": [ "Attribute name and value pairs", "Item country of origin code", "Attributes with tax or regulatory consequence", "Source of each attribute value" ] } ], "data_elements": [ { "id": "de-item-name", "name": "Item name", "description": "Short name identifying the supplied good or service.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-010" ] }, { "id": "de-item-standard-identifier", "name": "Standard item identifier", "description": "Item identifier from a registered global scheme, with the scheme identifier.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "de-item-party-identifier", "name": "Party-scoped item identifier", "description": "Seller, buyer or manufacturer item identifier valid only within that party's namespace.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-item-classification-code", "name": "Item classification code", "description": "Classification code with its classification system identifier and version.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "de-item-origin-country", "name": "Item country of origin", "description": "Country code identifying the origin of the supplied item.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "art-item-identification-block", "name": "Item identification block", "description": "Per-line block capturing all asserted item identifiers with their schemes, classifications, attributes and the declared precedence between competing identifier schemes.", "media_or_form": [ "structured record", "embedded line section" ], "serial": false, "identity_strategy": "Keyed by document authoritative identifier plus line identifier; item-level linkage uses the authoritative item identifier where one exists.", "source_refs": [ "SRC-004", "SRC-001" ] } ], "inline_only_rationale": null }, { "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.", "source_refs": [ "SRC-004", "SRC-001", "SRC-008", "SRC-005" ], "questions": [ { "id": "q-price-basis", "text": "On what basis is the item price expressed, including base quantity and any gross price and discount?", "kind": "measurement", "answer_data": [ "Item net price value", "Base quantity and its unit code", "Gross price and price discount where present", "Currency in which the price is expressed" ] }, { "id": "q-allowance-reason", "text": "What reason and reason code justifies each allowance or charge, and from which code list is the code drawn?", "kind": "classification", "answer_data": [ "Allowance or charge indicator", "Reason text and reason code", "Code list identifier and version", "Level at which it applies (line or document)" ] }, { "id": "q-allowance-tax", "text": "Which tax category and rate apply to each allowance or charge, and how does that interact with the document tax breakdown?", "kind": "constraint", "answer_data": [ "Tax category code and rate for the allowance or charge", "Contribution to each tax breakdown group", "Rule identifiers governing the interaction", "Handling where the category differs from the related line" ] }, { "id": "q-allowance-percentage-base", "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?", "kind": "validation", "answer_data": [ "Base amount value", "Percentage value", "Resulting amount stated on the document", "Consistency check outcome between percentage, base and amount" ] } ], "data_elements": [ { "id": "de-item-net-price", "name": "Item net price", "description": "Price of the item after any price discount, exclusive of tax.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-base-quantity", "name": "Price base quantity", "description": "Quantity to which the item price applies, with its unit code.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-allowance-charge-entry", "name": "Allowance or charge entry", "description": "An allowance or charge with indicator, amount, optional base and percentage, reason, reason code and tax category.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-001" ] }, { "id": "de-allowance-reason-code", "name": "Allowance or charge reason code", "description": "Governed code stating why the allowance or charge applies.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "art-pricing-and-adjustment-schedule", "name": "Pricing and adjustment schedule", "description": "Consolidated schedule of prices, base quantities and all line- and document-level allowances and charges with reasons, codes, bases and tax categories, sufficient to reproduce every total independently.", "media_or_form": [ "structured collection", "tabular rendition" ], "serial": false, "identity_strategy": "Keyed by document authoritative identifier; entries keyed by level, line identifier where applicable, and reason code.", "source_refs": [ "SRC-004", "SRC-001" ] } ], "inline_only_rationale": null } ] } ] }, { "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.", "rationale": "Tax breakdown, totals and payment instructions are named core elements of an electronic invoice and are the parts most tightly constrained by arithmetic business rules; they are also where an agent most easily produces a plausible but invalid document.", "source_refs": [ "SRC-008", "SRC-004", "SRC-005" ], "layers": [ { "id": "lyr-tax-treatment", "name": "Tax treatment and breakdown", "description": "Tax categories, rates, exemptions and special regimes asserted by the document.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006" ], "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.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006", "SRC-010" ], "questions": [ { "id": "q-tax-grouping", "text": "How are amounts grouped into tax breakdown entries, and what defines a distinct group?", "kind": "composition", "answer_data": [ "Grouping key (category code plus rate)", "Taxable amount per group", "Tax amount per group", "Rule identifiers enforcing group completeness" ] }, { "id": "q-tax-exemption-reason", "text": "Where no tax or a zero rate is applied, what reason and governed reason code justify it?", "kind": "requirement", "answer_data": [ "Tax category code", "Exemption reason text", "Exemption reason code and code list version", "Legal reference supporting the exemption" ] }, { "id": "q-tax-reverse-charge", "text": "Does a reverse-charge or special regime apply, and what marking does the document carry as a result?", "kind": "classification", "answer_data": [ "Regime indicator and category code", "Required wording carried on the document", "Consequence for the tax amount stated", "Jurisdiction whose rule triggers the marking" ] }, { "id": "q-tax-representative", "text": "Is a tax representative involved, and how does that change the tax identifiers stated on the document?", "kind": "authority", "answer_data": [ "Tax representative party reference", "Tax representative registration identifier", "Jurisdiction of the representation", "Conditional element requirements triggered" ] } ], "data_elements": [ { "id": "de-tax-category-code", "name": "Tax category code", "description": "Governed code stating the tax category applied to an amount group.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "de-tax-rate", "name": "Tax rate", "description": "Percentage rate applied within a tax breakdown group.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-taxable-amount", "name": "Taxable amount per group", "description": "Sum of amounts subject to the group's category and rate.", "value_kind": "number", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-tax-amount-group", "name": "Tax amount per group", "description": "Tax calculated for the group.", "value_kind": "number", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-exemption-reason-code", "name": "Tax exemption reason code", "description": "Governed code justifying a zero, exempt or out-of-scope category, with code list version.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "art-tax-breakdown-statement", "name": "Tax breakdown statement", "description": "The complete set of tax breakdown groups with categories, rates, taxable and tax amounts, exemption reasons and codes, sufficient for an authority to reconstruct the tax position of the document.", "media_or_form": [ "structured collection", "tabular rendition", "embedded document section" ], "serial": false, "identity_strategy": "Keyed by document authoritative identifier; groups keyed by category code plus rate.", "source_refs": [ "SRC-004", "SRC-005" ] } ], "inline_only_rationale": null } ] }, { "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.", "source_refs": [ "SRC-004", "SRC-006", "SRC-005" ], "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.", "source_refs": [ "SRC-004", "SRC-006", "SRC-010", "SRC-005" ], "questions": [ { "id": "q-currency-document", "text": "In which currency are the document amounts expressed, and from which code list is the currency code drawn?", "kind": "identity", "answer_data": [ "Document currency code", "Code list identifier and version", "Scope of amounts governed by that currency", "Rule forbidding mixed currencies in the same amount set" ] }, { "id": "q-currency-tax-accounting", "text": "Is a separate tax accounting currency required, and what tax amount is stated in it?", "kind": "requirement", "answer_data": [ "Tax accounting currency code", "Tax total amount in that currency", "Jurisdictional rule requiring the second statement", "Relationship rule between the two tax amounts" ] }, { "id": "q-currency-conversion-basis", "text": "What exchange rate, rate source and rate date underpin any conversion, and is that basis stated or merely assumed?", "kind": "provenance", "answer_data": [ "Exchange rate value", "Rate source and publishing authority", "Rate reference date", "Statement of whether the basis is carried on the document or held externally" ] }, { "id": "q-currency-rounding", "text": "How many decimal places apply to amounts in each currency and how are half-values rounded?", "kind": "constraint", "answer_data": [ "Decimal precision per currency", "Rounding mode applied", "Rule identifiers governing precision", "Handling of currencies with non-standard minor units" ] } ], "data_elements": [ { "id": "de-document-currency", "name": "Document currency code", "description": "Currency in which all document amounts are expressed.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "de-tax-accounting-currency", "name": "Tax accounting currency code", "description": "National currency in which the tax amount must additionally be stated where required.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-006" ] }, { "id": "de-tax-total-accounting-currency", "name": "Tax total in accounting currency", "description": "Tax total expressed in the tax accounting currency.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-exchange-rate-basis", "name": "Exchange rate basis", "description": "Rate value, publishing source and reference date used for any currency conversion.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Currency selection and conversion basis are scalar assertions carried inside the document and the tax breakdown statement; they produce no independent artefact of their own. The rate source is a reference to an externally governed rate publication owned by a monetary authority, not an artefact this model creates or stores. Where a jurisdiction requires evidence of the rate used, that evidence is captured as a supporting attachment under the attachments finding rather than duplicated here." }, { "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.", "source_refs": [ "SRC-004", "SRC-002", "SRC-005", "SRC-008" ], "questions": [ { "id": "q-totals-set", "text": "Which total amounts must be stated explicitly rather than left for the receiver to compute?", "kind": "requirement", "answer_data": [ "Sum of line net amounts", "Document allowance and charge totals", "Tax exclusive and tax inclusive totals", "Prepaid amount, rounding amount and amount due" ] }, { "id": "q-totals-reconciliation", "text": "How is each stated total reconciled against its constituent parts, and what tolerance is permitted?", "kind": "validation", "answer_data": [ "Reconciliation expression per total", "Rule identifiers that fire on mismatch", "Permitted tolerance and its basis", "Outcome and evidence of the last reconciliation run" ] }, { "id": "q-totals-rounding-amount", "text": "When a rounding amount is stated, what does it represent and how is it constrained?", "kind": "constraint", "answer_data": [ "Rounding amount value and sign", "Purpose of the rounding (payment convenience, cash rounding)", "Constraint bounding the permitted magnitude", "Effect on amount due" ] }, { "id": "q-totals-prepaid", "text": "How does a prepaid amount interact with the amount due, and where does the evidence for the prepayment live?", "kind": "relationship", "answer_data": [ "Prepaid amount value", "Reference to the prepayment evidence or prior document", "Resulting amount due", "Statement that settlement state is held in the payment model" ] } ], "data_elements": [ { "id": "de-line-extension-total", "name": "Sum of line net amounts", "description": "Aggregate of all invoice line net amounts.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-tax-exclusive-total", "name": "Total without tax", "description": "Document total before tax, after document allowances and charges.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-tax-inclusive-total", "name": "Total with tax", "description": "Document total including tax.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-prepaid-amount", "name": "Prepaid amount", "description": "Amount already paid and deducted from the amount due.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-rounding-amount", "name": "Rounding amount", "description": "Adjustment applied to reach a rounded amount due.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-amount-due", "name": "Amount due for payment", "description": "Amount the buyer is requested to pay as asserted at issue time.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "art-totals-reconciliation-report", "name": "Totals reconciliation report", "description": "Machine-checkable report recording each total, its recomputed value from constituent parts, the rule identifiers applied, the tolerance used and the pass or fail outcome with the instant of execution.", "media_or_form": [ "validation report", "structured record" ], "serial": true, "identity_strategy": "Keyed by document authoritative identifier plus rule set version plus execution sequence number.", "source_refs": [ "SRC-005", "SRC-004" ] } ], "inline_only_rationale": null } ] }, { "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.", "source_refs": [ "SRC-004", "SRC-003", "SRC-008" ], "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.", "source_refs": [ "SRC-004", "SRC-003", "SRC-008", "SRC-006" ], "questions": [ { "id": "q-payment-means", "text": "By what means is payment requested, and what account, card or mandate details support that means?", "kind": "process", "answer_data": [ "Payment means code and code list version", "Payee account identifier and account name", "Card or direct debit mandate details where applicable", "Payee party reference where it differs from the seller" ] }, { "id": "q-payment-due", "text": "When is payment due, and how is the due date derived from the terms when only terms are stated?", "kind": "temporal", "answer_data": [ "Payment due date value", "Payment terms text", "Derivation rule from terms to date", "Requirement that one of due date or terms is present" ] }, { "id": "q-payment-reference", "text": "What remittance or payment reference must the payer quote, and how does it enable reconciliation?", "kind": "relationship", "answer_data": [ "Payment or remittance reference value", "Structured versus unstructured reference form", "Reconciliation mechanism it feeds", "Consequence of the reference being omitted or altered" ] }, { "id": "q-payment-settlement-boundary", "text": "Where is settlement state recorded, and what prevents it being stored as a mutable field on the issued document?", "kind": "state", "answer_data": [ "Reference to the settlement record set", "Rule forbidding mutation of issued document fields", "Derivation path for the current outstanding amount", "Actor authorised to assert settlement state" ] } ], "data_elements": [ { "id": "de-payment-means-code", "name": "Payment means code", "description": "Governed code indicating how payment is to be made.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "de-payee-account", "name": "Payee account identifier", "description": "Account to which payment should be directed, with the account scheme and account name.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-payment-terms", "name": "Payment terms", "description": "Textual statement of payment conditions including any discount or penalty terms.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-payment-due-date", "name": "Payment due date", "description": "Calendar date by which payment is requested.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-remittance-reference", "name": "Remittance reference", "description": "Reference the payer is asked to quote so that the payment can be matched to this document.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-003" ] } ], "artifacts": [ { "id": "art-payment-instruction-block", "name": "Payment instruction block", "description": "The consolidated payment instruction as asserted at issue: means, accounts or mandates, terms, due date and remittance reference, frozen with the document and never updated by settlement events.", "media_or_form": [ "structured record", "embedded document section" ], "serial": false, "identity_strategy": "Keyed by document authoritative identifier; payee account linked to its master banking record identifier where governed.", "source_refs": [ "SRC-004", "SRC-003" ] } ], "inline_only_rationale": null } ] } ] }, { "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.", "rationale": "Contract reference, delivery details and supporting document references are named core elements, and the correction chain is the only lawful way to change an issued invoice; both must be modelled as first-class relationships rather than free text.", "source_refs": [ "SRC-008", "SRC-004", "SRC-010", "SRC-013" ], "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.", "source_refs": [ "SRC-004", "SRC-001", "SRC-010" ], "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.", "source_refs": [ "SRC-004", "SRC-001", "SRC-008" ], "questions": [ { "id": "q-refs-typed-set", "text": "Which typed commercial references does this document carry and what is each one for?", "kind": "relationship", "answer_data": [ "Order and sales order reference values", "Contract reference value", "Despatch advice and receiving advice references", "Tender or lot and project references", "Purpose statement per reference type" ] }, { "id": "q-refs-buyer-routing", "text": "What buyer-supplied reference is present for the buyer's own internal routing, and how does it differ from a commercial reference?", "kind": "interoperability", "answer_data": [ "Buyer reference value", "Distinction from order reference", "Consequence of an incorrect buyer reference", "Requirement status in the governing specification" ] }, { "id": "q-refs-matching", "text": "What matching is performed against these references before acceptance, and at which level does it operate?", "kind": "process", "answer_data": [ "Matching mode (two-way, three-way, line-level)", "Matched and unmatched line identifiers", "Tolerance rules applied to quantity and price", "Matching outcome with the instant of execution" ] }, { "id": "q-refs-integrity", "text": "How is a dangling or unresolvable reference detected and handled?", "kind": "exception", "answer_data": [ "Resolution attempt result per reference", "Unresolvable reference list", "Handling policy (reject, accept with flag, request clarification)", "Actor responsible for resolution" ] } ], "data_elements": [ { "id": "de-order-reference", "name": "Purchase order reference", "description": "Identifier of the buyer's purchase order.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-contract-reference", "name": "Contract reference", "description": "Identifier of the governing contract or framework agreement.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-008" ] }, { "id": "de-despatch-reference", "name": "Despatch advice reference", "description": "Identifier of the despatch advice evidencing the supply.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-receipt-reference", "name": "Receiving advice reference", "description": "Identifier of the buyer's goods receipt record.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-buyer-reference", "name": "Buyer reference", "description": "Buyer-supplied value used for the buyer's internal routing and cost allocation.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-003" ] } ], "artifacts": [ { "id": "art-matching-result-record", "name": "Matching result record", "description": "Record of a matching run linking the document and its lines to the referenced order and receipt records, with per-line outcomes, applied tolerances and unresolved references.", "media_or_form": [ "structured record", "reconciliation report" ], "serial": true, "identity_strategy": "Keyed by document authoritative identifier plus matching run sequence number; references resolved to the master identifiers of the linked records.", "source_refs": [ "SRC-004", "SRC-001" ] } ], "inline_only_rationale": null }, { "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.", "source_refs": [ "SRC-010", "SRC-004", "SRC-006", "SRC-003" ], "questions": [ { "id": "q-correction-preceding-ref", "text": "Which preceding document does this document amend, and how specifically and unambiguously is it identified?", "kind": "relationship", "answer_data": [ "Preceding document identifier and its issue date", "Identifier scheme used for the reference", "Referenced line identifiers where the correction is partial", "Assessment that the reference is unambiguous" ] }, { "id": "q-correction-mechanism", "text": "Which correction mechanism is lawful in the governing jurisdiction for this document type, and why was it chosen?", "kind": "decision", "answer_data": [ "Mechanism used (credit note, debit note, corrective invoice, cancellation)", "Jurisdictional basis for the choice", "Alternatives rejected and why", "Effect on the original document's validity" ] }, { "id": "q-correction-immutability", "text": "What guarantees that the corrected original remains retrievable and unmodified after correction?", "kind": "constraint", "answer_data": [ "Immutability control applied to the original", "Digest of the original recorded before correction", "Retrieval path for the superseded document", "Actor authorised to assert supersession" ] }, { "id": "q-correction-net-effect", "text": "How is the net commercial effect of a correction chain computed across all linked documents?", "kind": "measurement", "answer_data": [ "Ordered chain of linked document identifiers", "Signed amount contribution per document", "Resulting net claim", "Rule preventing double counting" ] } ], "data_elements": [ { "id": "de-preceding-document-reference", "name": "Preceding document reference", "description": "Identifier and issue date of the document being amended.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-010" ] }, { "id": "de-correction-mechanism", "name": "Correction mechanism", "description": "The lawful mechanism by which the preceding document is amended.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-010" ] }, { "id": "de-supersession-link", "name": "Supersession link", "description": "Typed link asserting that this document supersedes or partially reverses another.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-net-claim-amount", "name": "Net claim amount", "description": "Computed net commercial effect across the correction chain, held as derived data rather than as a document field.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "art-correction-chain-graph", "name": "Correction chain graph", "description": "Directed graph of billing documents linked by supersession, credit and debit relations, with signed amount contributions and the digest of each superseded document, enabling the net claim to be recomputed and audited.", "media_or_form": [ "typed edge set", "graph projection", "structured record set" ], "serial": false, "identity_strategy": "Nodes keyed by each document's authoritative identifier; edges keyed by source identifier, target identifier and relation type.", "source_refs": [ "SRC-004", "SRC-010" ] } ], "inline_only_rationale": null } ] }, { "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.", "source_refs": [ "SRC-004", "SRC-013", "SRC-011" ], "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.", "source_refs": [ "SRC-004", "SRC-013", "SRC-011", "SRC-006" ], "questions": [ { "id": "q-attachment-inventory", "text": "What supporting objects are attached or referenced, and is each embedded or held externally?", "kind": "composition", "answer_data": [ "Attachment identifier and description", "Media type and filename", "Embedded binary or external locator", "Reason the attachment is required or useful" ] }, { "id": "q-rendition-precedence", "text": "Where a hybrid carrier holds both a visual and a structured representation, which one prevails if they disagree?", "kind": "authority", "answer_data": [ "Precedence declaration and its jurisdictional basis", "Profile level of the structured representation", "Detected divergence between representations", "Remediation path when divergence is found" ] }, { "id": "q-rendition-legibility", "text": "How is legibility of the human-readable form guaranteed throughout the storage period?", "kind": "quality", "answer_data": [ "Rendition format and preservation profile", "Font, resource and colour-space embedding evidence", "Periodic legibility check outcomes with instants", "Migration policy if the format becomes unreadable" ] }, { "id": "q-attachment-integrity", "text": "How is the integrity of each attachment bound to the invoice that carries it?", "kind": "security", "answer_data": [ "Digest and algorithm per attachment", "Binding of digests into the signed or sealed scope", "Verification outcome and observing actor", "Handling of attachments outside the signature scope" ] } ], "data_elements": [ { "id": "de-attachment-entry", "name": "Attachment entry", "description": "A supporting object with identifier, description, media type, filename and either embedded content or an external locator.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-attachment-digest", "name": "Attachment digest", "description": "Cryptographic digest of the attachment bytes with the algorithm identifier.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-rendition-format", "name": "Rendition format", "description": "Format and preservation profile of the human-readable rendition.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-representation-precedence", "name": "Representation precedence", "description": "Declaration of which representation prevails where a hybrid carrier holds both structured and visual forms.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-011" ] } ], "artifacts": [ { "id": "art-hybrid-carrier-file", "name": "Hybrid invoice carrier", "description": "A single file that carries the human-readable rendition together with the embedded structured invoice data at a declared profile level, with digests for both representations and the precedence declaration.", "media_or_form": [ "archival page-description document with embedded structured data", "structured data file plus rendition pair" ], "serial": false, "identity_strategy": "Keyed by document authoritative identifier plus representation role; content addressed by digest for integrity checks.", "source_refs": [ "SRC-013", "SRC-011" ] }, { "id": "art-supporting-attachment", "name": "Supporting attachment object", "description": "An individual supporting document such as a timesheet, proof of delivery or specification, held as bytes or as a governed external reference with its digest and media type.", "media_or_form": [ "binary object", "external reference with digest" ], "serial": false, "identity_strategy": "Keyed by the attachment's own registered identifier where one exists, otherwise by document authoritative identifier plus attachment identifier.", "source_refs": [ "SRC-004" ] } ], "inline_only_rationale": null } ] } ] }, { "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.", "rationale": "Authenticity of origin, integrity of content and legibility are explicit legal requirements from issue to the end of the storage period, satisfiable by business controls creating a reliable audit trail as well as by signatures or EDI; clearance regimes add a further authority-side step that changes the lifecycle.", "source_refs": [ "SRC-010", "SRC-011", "SRC-007", "SRC-005" ], "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.", "source_refs": [ "SRC-010", "SRC-012", "SRC-003" ], "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.", "source_refs": [ "SRC-010", "SRC-007", "SRC-012", "SRC-006" ], "questions": [ { "id": "q-lifecycle-state-set", "text": "What is the permitted state set for this document type and which transitions are legal between them?", "kind": "lifecycle", "answer_data": [ "Enumerated states with definitions", "Permitted transitions and their triggers", "Terminal states", "Actor authorised for each transition" ] }, { "id": "q-lifecycle-immutability", "text": "At which point does content become immutable, and what technical control enforces that?", "kind": "state", "answer_data": [ "Immutability trigger event and its instant", "Enforcing control (digest, seal, write-once store)", "Fields that may still change and why", "Consequence of detected post-issue modification" ] }, { "id": "q-lifecycle-clearance-insertion", "text": "Does a clearance or registration step sit between issue and delivery, and what does that change about the state model?", "kind": "process", "answer_data": [ "Clearance requirement indicator and jurisdiction", "Inserted state and its entry and exit conditions", "Deadline for the clearance step", "Status of a document delivered without clearance" ] }, { "id": "q-lifecycle-event-record", "text": "How is each transition recorded so that the state history can be reconstructed independently of current state?", "kind": "event", "answer_data": [ "Transition event type", "Event instant with explicit offset", "Acting party and acting system", "Prior and resulting state values" ] } ], "data_elements": [ { "id": "de-lifecycle-state", "name": "Lifecycle state", "description": "Current state of the document within its permitted state set.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-010", "SRC-012" ] }, { "id": "de-transition-event", "name": "Transition event", "description": "A recorded state transition with type, instant, actor and prior and resulting states.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-012" ] }, { "id": "de-immutability-instant", "name": "Immutability instant", "description": "RFC 3339 instant at which content became immutable.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-clearance-required-indicator", "name": "Clearance requirement indicator", "description": "Whether a tax-authority clearance step is required before lawful delivery.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "art-lifecycle-event-log", "name": "Lifecycle event log", "description": "Append-only log of every state transition with type, instant, acting party, acting system and prior and resulting states, from which current state is derived rather than stored authoritatively.", "media_or_form": [ "append-only event log", "structured record set" ], "serial": true, "identity_strategy": "Keyed by document authoritative identifier plus monotonically increasing event sequence; no date-derived keys.", "source_refs": [ "SRC-012", "SRC-009" ] } ], "inline_only_rationale": null }, { "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.", "source_refs": [ "SRC-012", "SRC-003", "SRC-006", "SRC-010" ], "questions": [ { "id": "q-response-kinds", "text": "What response kinds may a receiver return, and what does each one commit the receiver to?", "kind": "process", "answer_data": [ "Response kind enumeration", "Commitment implied by each kind", "Response deadline where one exists", "Silence semantics where no response is returned" ] }, { "id": "q-response-reason-coding", "text": "How is a rejection or dispute reason coded so that the issuer can act on it without human reading?", "kind": "classification", "answer_data": [ "Reason code and code list version", "Free-text clarification", "Affected line identifiers or elements", "Suggested remediation action" ] }, { "id": "q-response-authority", "text": "Who within the receiving organisation is authorised to accept, reject or dispute, and how is that authority evidenced?", "kind": "authority", "answer_data": [ "Authorised role and its holder", "Delegation or approval evidence", "Monetary or category limits on the authority", "Escalation path when the limit is exceeded" ] }, { "id": "q-response-effect", "text": "What effect does a dispute have on the payment due date and on retention obligations?", "kind": "state", "answer_data": [ "Dispute state and its start instant", "Effect on the asserted due date", "Effect on disposition eligibility", "Resolution instant and outcome" ] } ], "data_elements": [ { "id": "de-response-kind", "name": "Response kind", "description": "The business response returned by the receiver.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-003" ] }, { "id": "de-response-reason-code", "name": "Response reason code", "description": "Coded reason for rejection, conditional acceptance or dispute.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-response-instant", "name": "Response instant", "description": "RFC 3339 instant at which the response was issued by the receiver.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-dispute-state", "name": "Dispute state", "description": "Whether the document is under dispute and the scope of that dispute.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "art-business-response-message", "name": "Business response message", "description": "A returned message carrying the response kind, coded reasons, affected elements and the responding party, distinct from any transport-level acknowledgement.", "media_or_form": [ "structured message", "envelope payload", "status record" ], "serial": true, "identity_strategy": "Keyed by its own message identifier from the responding system, linked to the referenced document's authoritative identifier.", "source_refs": [ "SRC-012", "SRC-003" ] } ], "inline_only_rationale": null }, { "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.", "source_refs": [ "SRC-022", "SRC-015", "SRC-019", "SRC-016" ], "questions": [ { "id": "fnd-self-billing-prepayment-and-special-processes-q01", "text": "Is this a self-billed invoice, which agreement authorises it, and has the supplier accepted or disputed it?", "kind": "process", "answer_data": [ "selfBillingFlag", "selfBillingAgreementRef", "supplierAcceptanceStatus", "disputeNoticeId" ] }, { "id": "fnd-self-billing-prepayment-and-special-processes-q02", "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?", "kind": "relationship", "answer_data": [ "prepaymentFlag", "relatedPrepaymentInvoiceIds", "prepaidAmount" ] }, { "id": "fnd-self-billing-prepayment-and-special-processes-q03", "text": "Is the invoice consolidated, consignment (non-sale), factored or freight-charge billing, and which process rules then apply?", "kind": "classification", "answer_data": [ "consolidatedFlag", "consignmentFlag", "factoredFlag", "freightInvoiceFlag" ] } ], "data_elements": [ { "id": "fnd-self-billing-prepayment-and-special-processes-data01", "name": "selfBillingFlag", "description": "Whether the customer raised the invoice in the supplier's name, requiring the Article 226(10a) mention 'Self-billing'.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-015", "SRC-019" ] }, { "id": "fnd-self-billing-prepayment-and-special-processes-data02", "name": "selfBillingAgreementRef", "description": "Reference to the agreement that authorises the customer to issue invoices on behalf of the supplier.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-019" ] }, { "id": "fnd-self-billing-prepayment-and-special-processes-data03", "name": "prepaymentFlag", "description": "Whether the instance is a prepayment invoice (type 386) collecting amounts to be subtracted from a final invoice.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-016" ] }, { "id": "fnd-self-billing-prepayment-and-special-processes-data04", "name": "consolidatedFlag", "description": "Whether the instance is a consolidated invoice variant named by UN/CEFACT CII.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "fnd-self-billing-prepayment-and-special-processes-data05", "name": "consignmentFlag", "description": "Whether the instance is a consignment (non-sale) invoice variant, UNCL 1001 code 395.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "fnd-self-billing-prepayment-and-special-processes-data06", "name": "disputeNoticeId", "description": "Reference to the dispute notice the supplier raises when reconciliation of a self-billing invoice finds a discrepancy.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-022" ] } ], "artifacts": [ { "id": "fnd-self-billing-prepayment-and-special-processes-artifact01", "name": "Self-billed invoice", "description": "Invoice issued by the customer in the name of the supplier under a self-billing agreement, including the Self-billing mention.", "media_or_form": [ "UBL XML", "UN/CEFACT CII XML", "JSON projection" ], "serial": true, "identity_strategy": "Identified by the sequential number assigned by the issuing customer under the self-billing agreement, bound to the supplier party whose supply it documents.", "source_refs": [ "SRC-015", "SRC-022", "SRC-019" ] } ], "inline_only_rationale": null } ] }, { "id": "lyr-authenticity-and-clearance", "name": "Authenticity, integrity and authority clearance", "description": "The controls and authority acts that make the document trustworthy as evidence.", "source_refs": [ "SRC-010", "SRC-011", "SRC-007", "SRC-013" ], "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.", "source_refs": [ "SRC-011", "SRC-010", "SRC-006", "SRC-013" ], "questions": [ { "id": "q-authenticity-method", "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?", "kind": "security", "answer_data": [ "Assurance method (business controls, electronic signature or seal, EDI)", "Statement of whether the method is legally required or elective", "Jurisdiction whose rule applies", "Method identifier and parameters" ] }, { "id": "q-authenticity-audit-trail", "text": "What reliable audit trail links this invoice to the underlying supply, and which documents form it?", "kind": "evidence", "answer_data": [ "Ordered set of linking documents (order, delivery, receipt, contract)", "Description of the control that creates the link", "Gaps in the trail and their justification", "Actor responsible for maintaining the trail" ] }, { "id": "q-authenticity-signature-scope", "text": "Where a signature or seal is applied, what exact byte scope does it cover and what does it leave unprotected?", "kind": "validation", "answer_data": [ "Signed byte scope description", "Elements or attachments outside the scope", "Signature format and level", "Verification outcome with instant and verifying actor" ] }, { "id": "q-authenticity-longevity", "text": "How is assurance maintained for the whole storage period as algorithms and certificates age?", "kind": "quality", "answer_data": [ "Long-term validation or archival timestamp strategy", "Certificate and algorithm expiry dates", "Re-protection schedule and last execution instant", "Fallback where re-protection was not performed" ] } ], "data_elements": [ { "id": "de-assurance-method", "name": "Assurance method", "description": "Declared method by which authenticity of origin and integrity of content are assured.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-010" ] }, { "id": "de-content-digest", "name": "Content digest", "description": "Cryptographic digest over the canonical byte form of the business document, with the algorithm identifier.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-signature-record", "name": "Signature or seal record", "description": "Signature or seal with signer or sealer reference, format, level, signing instant and covered scope.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-010" ] }, { "id": "de-audit-trail-link", "name": "Audit trail link", "description": "Typed link from the invoice to a document that forms part of the reliable audit trail to the supply.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [ { "id": "art-integrity-evidence-set", "name": "Integrity evidence set", "description": "Bundle of digests, signature or seal records, timestamp tokens and verification outcomes for the document and its attachments, retained for the whole storage period.", "media_or_form": [ "structured evidence record", "detached signature or token set" ], "serial": true, "identity_strategy": "Keyed by document authoritative identifier plus evidence sequence; each element content-addressed by its digest.", "source_refs": [ "SRC-013", "SRC-011" ] }, { "id": "art-business-control-description", "name": "Business control description", "description": "Documented description of the business controls that create the reliable audit trail between the invoice and the supply, usable as evidence to an auditor where no signature is applied.", "media_or_form": [ "control narrative", "policy document", "structured control register entry" ], "serial": false, "identity_strategy": "Keyed by the control register identifier in the issuer's control system of record.", "source_refs": [ "SRC-011", "SRC-006" ] } ], "inline_only_rationale": null }, { "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.", "source_refs": [ "SRC-007", "SRC-005", "SRC-006", "SRC-010" ], "questions": [ { "id": "q-clearance-regime", "text": "Which clearance or reporting regime governs this document, and is registration a precondition of validity or a subsequent reporting duty?", "kind": "authority", "answer_data": [ "Regime name and governing jurisdiction", "Precondition versus post-issue reporting classification", "Legal consequence of non-registration", "Applicability threshold that brought the document into scope" ] }, { "id": "q-clearance-identifier", "text": "What identifier, acknowledgement and signed code does the authority return, and how are they bound to the document?", "kind": "identity", "answer_data": [ "Authority-assigned identifier value and scheme", "Acknowledgement reference and instant with explicit offset", "Signed code or machine-readable token", "Binding to the document digest" ] }, { "id": "q-clearance-deadline", "text": "Within what deadline must registration occur, measured from which event?", "kind": "temporal", "answer_data": [ "Deadline duration and its measurement basis", "Reference event and its instant", "Compliance assessment outcome", "Consequence of a missed deadline" ] }, { "id": "q-clearance-failure", "text": "What happens when clearance is rejected or unavailable, and what interim status may the document hold?", "kind": "exception", "answer_data": [ "Rejection reason returned by the authority", "Permitted interim status and its limits", "Retry or offline provisions", "Remediation and resubmission record" ] } ], "data_elements": [ { "id": "de-clearance-identifier", "name": "Clearance identifier", "description": "Identifier assigned by the tax authority or its agent upon registration of the document.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-006" ] }, { "id": "de-clearance-instant", "name": "Clearance acknowledgement instant", "description": "RFC 3339 instant at which the authority acknowledged registration, with explicit offset.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-007" ] }, { "id": "de-clearance-token", "name": "Clearance token", "description": "Signed code or machine-readable token returned by the authority and required to be carried on the document.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-clearance-status", "name": "Clearance status", "description": "Outcome of the registration attempt, including rejection reasons where applicable.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "art-clearance-response", "name": "Clearance response record", "description": "The authority's response as received: assigned identifier, acknowledgement reference and instant, signed token, status and any rejection reasons, retained as the evidence that the document was lawfully registered.", "media_or_form": [ "authority response message", "structured record", "signed token" ], "serial": true, "identity_strategy": "Keyed by the authority-assigned identifier, which is treated as the master-system identifier for the governing jurisdiction.", "source_refs": [ "SRC-007", "SRC-006" ] } ], "inline_only_rationale": null } ] }, { "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.", "source_refs": [ "SRC-010", "SRC-006", "SRC-005", "SRC-003" ], "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.", "source_refs": [ "SRC-010", "SRC-006", "SRC-005", "SRC-008" ], "questions": [ { "id": "q-particulars-applicable-set", "text": "Which jurisdiction's particulars apply to this document, and what determines that jurisdiction?", "kind": "requirement", "answer_data": [ "Governing jurisdiction and its determination basis", "Applicable particulars list identifier", "Full versus simplified invoice determination", "Threshold or condition that triggered the reduced set" ] }, { "id": "q-particulars-conditional", "text": "Which conditional particulars are triggered by this document's circumstances, such as exemption, reverse charge, margin scheme or self-billing?", "kind": "constraint", "answer_data": [ "Triggered condition list", "Required wording or code per condition", "Presence check outcome per requirement", "Justification for any absent particular" ] }, { "id": "q-particulars-national-specification", "text": "Which national or sectoral usage specification applies on top of the core model, and what does it change?", "kind": "interoperability", "answer_data": [ "Usage specification identifier and version", "Registry entry reference", "Restrictions and additions relative to the core", "Effect on cross-border acceptance" ] }, { "id": "q-particulars-language", "text": "In which language is the document issued, and what translation obligation applies for audit during the storage period?", "kind": "access", "answer_data": [ "Document language code", "Translation obligation and its trigger", "Party responsible for producing a translation", "Deadline for supplying a translation on request" ] } ], "data_elements": [ { "id": "de-governing-jurisdiction", "name": "Governing jurisdiction", "description": "Jurisdiction whose invoicing rules govern this document, with the basis of that determination.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-010", "SRC-006" ] }, { "id": "de-particulars-profile", "name": "Particulars profile", "description": "Identifier of the applicable particulars set (full, simplified, special regime).", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-010" ] }, { "id": "de-conditional-requirement", "name": "Conditional requirement", "description": "A requirement triggered by the document's circumstances, with its required wording or code.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-005" ] }, { "id": "de-document-language", "name": "Document language", "description": "Language in which the document is issued.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "art-particulars-requirement-matrix", "name": "Particulars requirement matrix", "description": "Jurisdiction-by-condition matrix stating which particulars are mandatory, conditional or forbidden, mapped to the model's data elements and to the rule identifiers that test them.", "media_or_form": [ "requirement matrix", "structured reference data", "rule mapping table" ], "serial": false, "identity_strategy": "Keyed by jurisdiction code plus particulars profile plus matrix version.", "source_refs": [ "SRC-010", "SRC-005" ] } ], "inline_only_rationale": null }, { "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.", "source_refs": [ "SRC-005", "SRC-003", "SRC-004", "SRC-002" ], "questions": [ { "id": "q-validation-rule-sets", "text": "Which rule sets and artefact versions were executed against this document, and which were not?", "kind": "validation", "answer_data": [ "Rule set identifiers and artefact versions", "Execution scope per rule set", "Rule sets deliberately not executed and why", "Executing system and its version" ] }, { "id": "q-validation-outcomes", "text": "What was the outcome per rule, and how are fatal errors distinguished from warnings?", "kind": "quality", "answer_data": [ "Per-rule outcome with severity", "Failed rule identifiers with located elements", "Aggregate pass or fail determination", "Instant of execution with explicit offset" ] }, { "id": "q-validation-drift", "text": "How is a document revalidated when rule sets are updated on their release cycle, and what does an old pass result mean afterwards?", "kind": "temporal", "answer_data": [ "Artefact release version at original validation", "Current artefact release version", "Revalidation policy and last revalidation outcome", "Statement of the evidential value of a superseded pass" ] }, { "id": "q-validation-disposition", "text": "What may a receiver do with a document that fails validation, and who decides?", "kind": "decision", "answer_data": [ "Permitted outcomes (reject, accept with exception, quarantine)", "Decision maker and authority basis", "Exception record with justification", "Notification obligation to the issuer" ] } ], "data_elements": [ { "id": "de-rule-set-identifier", "name": "Rule set identifier", "description": "Identifier and version of a validation rule set executed against the document.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-003" ] }, { "id": "de-rule-outcome", "name": "Rule outcome", "description": "Per-rule result with severity and the located element.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-validation-instant", "name": "Validation instant", "description": "RFC 3339 instant at which validation was executed, with explicit offset.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-validation-verdict", "name": "Validation verdict", "description": "Aggregate conformance determination for the executed rule sets.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "art-validation-report", "name": "Validation report", "description": "Retained report of a validation run: rule set identifiers and versions, per-rule outcomes with severities and locations, aggregate verdict, executing system and execution instant.", "media_or_form": [ "validation report", "structured record", "rule engine output" ], "serial": true, "identity_strategy": "Keyed by document authoritative identifier plus rule set version plus run sequence number.", "source_refs": [ "SRC-005", "SRC-003" ] } ], "inline_only_rationale": null } ] } ] }, { "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.", "rationale": "Syntax binding, network routing, storage obligations and role-scoped access are the operating surface an agent must handle to move an invoice between organisations lawfully; storage obligations and the acceptability of storage location are set by law, while transport is set by network specifications.", "source_refs": [ "SRC-012", "SRC-006", "SRC-010", "SRC-005" ], "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.", "source_refs": [ "SRC-001", "SRC-013", "SRC-012", "SRC-005" ], "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.", "source_refs": [ "SRC-001", "SRC-002", "SRC-013", "SRC-005" ], "questions": [ { "id": "q-syntax-selected", "text": "Which syntax binding carries this instance, and which syntax versions and code-list versions does it depend on?", "kind": "interoperability", "answer_data": [ "Syntax identifier and version", "Schema or schema module set referenced", "Code list identifiers and versions bound", "Profile level within the syntax where applicable" ] }, { "id": "q-syntax-fidelity", "text": "What semantic loss occurs when this instance is transformed into another supported syntax?", "kind": "quality", "answer_data": [ "Element-level mapping coverage", "Unmappable elements and their disposition", "Round-trip test outcome", "Party accountable for the transformation" ] }, { "id": "q-syntax-extensions", "text": "Does the instance carry extension content beyond the core semantic model, and how must a receiver treat it?", "kind": "composition", "answer_data": [ "Extension namespace and identifier", "Elements carried in the extension", "Receiver obligation (process, ignore, reject)", "Registry entry for the extension" ] }, { "id": "q-syntax-manifest-values", "text": "Are all calculated values explicitly present rather than left for the receiver to infer?", "kind": "constraint", "answer_data": [ "List of calculated values present in the instance", "Any omitted value and its justification", "Rule forbidding inference of omitted values", "Validation outcome for completeness" ] } ], "data_elements": [ { "id": "de-syntax-identifier", "name": "Syntax identifier", "description": "Identifier and version of the syntax binding used to serialise the instance.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-005" ] }, { "id": "de-code-list-binding", "name": "Code list binding", "description": "Identifier and version of each code list the instance depends on.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-extension-content", "name": "Extension content", "description": "Content carried beyond the core semantic model, with its governing namespace.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-008" ] }, { "id": "de-transformation-record", "name": "Transformation record", "description": "Record of a syntax transformation with source, target, mapping version, losses and executing actor.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-002" ] } ], "artifacts": [ { "id": "art-syntax-mapping-manifest", "name": "Syntax mapping manifest", "description": "Manifest binding each model data element to its location in every supported syntax, with the mapping version, unmappable elements and the round-trip fidelity result.", "media_or_form": [ "mapping manifest", "structured reference data" ], "serial": false, "identity_strategy": "Keyed by source syntax identifier plus target syntax identifier plus mapping version.", "source_refs": [ "SRC-001", "SRC-005" ] } ], "inline_only_rationale": null }, { "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.", "source_refs": [ "SRC-012", "SRC-003", "SRC-014", "SRC-005" ], "questions": [ { "id": "q-routing-identifiers", "text": "Which participant, document type and process identifiers address this transmission, and from which schemes are they drawn?", "kind": "identity", "answer_data": [ "Sender and receiver participant identifiers with scheme codes", "Document type identifier", "Process identifier", "Identifier policy version applied" ] }, { "id": "q-routing-discovery", "text": "How was the receiver's capability and endpoint discovered, and what was the state of that lookup at send time?", "kind": "process", "answer_data": [ "Service metadata lookup result", "Endpoint address and transport profile", "Capability match outcome for the document type", "Instant of the lookup with explicit offset" ] }, { "id": "q-routing-envelope", "text": "What envelope wraps the business document, and what does it assert that the document itself does not?", "kind": "composition", "answer_data": [ "Envelope specification and version", "Envelope header fields and their values", "Relationship between envelope identifiers and document identifiers", "Rule excluding the envelope from the business document digest" ] }, { "id": "q-routing-delivery-evidence", "text": "What evidence exists that the document was delivered, and how is it distinguished from business acceptance?", "kind": "evidence", "answer_data": [ "Transport receipt or acknowledgement reference", "Delivery instant with explicit offset", "Explicit statement that receipt is not acceptance", "Link to any separate business response" ] } ], "data_elements": [ { "id": "de-participant-identifier", "name": "Participant identifier", "description": "Network address of a sender or receiver, with its scheme code.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-document-type-identifier", "name": "Document type identifier", "description": "Network-level identifier of the document type and customization being exchanged.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-003" ] }, { "id": "de-envelope-header", "name": "Envelope header", "description": "Message envelope header carrying routing and typing metadata around the business document.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-transport-receipt", "name": "Transport receipt", "description": "Acknowledgement of delivery at transport level, with reference and instant.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-009" ] } ], "artifacts": [ { "id": "art-transmission-record", "name": "Transmission record", "description": "Record of one transmission attempt: routing identifiers, discovery result, envelope headers, transport profile, outcome, receipt reference and instants, retained as delivery evidence.", "media_or_form": [ "structured record", "transport log entry", "signed receipt" ], "serial": true, "identity_strategy": "Keyed by the envelope message identifier assigned by the sending access point, linked to the document authoritative identifier.", "source_refs": [ "SRC-012", "SRC-003" ] } ], "inline_only_rationale": null } ] }, { "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.", "source_refs": [ "SRC-006", "SRC-010", "SRC-011" ], "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.", "source_refs": [ "SRC-006", "SRC-010", "SRC-011" ], "questions": [ { "id": "q-retention-period", "text": "What retention period applies to this document, from which trigger event is it measured, and which jurisdiction sets it?", "kind": "retention", "answer_data": [ "Retention period duration", "Trigger event and its date or instant", "Setting jurisdiction and legal basis", "Computed earliest disposition date" ] }, { "id": "q-retention-conditions", "text": "What conditions must storage preserve for the whole period, and how is compliance monitored?", "kind": "quality", "answer_data": [ "Preserved properties (authenticity, integrity, legibility)", "Storage location and any cross-border constraint", "Monitoring checks performed and their instants", "Remediation record for detected degradation" ] }, { "id": "q-retention-hold", "text": "How is disposition suspended by a legal hold or dispute, and how is the suspension evidenced and lifted?", "kind": "exception", "answer_data": [ "Hold identifier, reason and placing authority", "Hold placement and release instants", "Documents and evidence within the hold scope", "Rule that a hold never alters record content" ] }, { "id": "q-retention-erasure-conflict", "text": "How is a personal-data erasure request reconciled with a statutory retention obligation on the same document?", "kind": "privacy", "answer_data": [ "Personal data elements identified on the document", "Legal basis asserted for continued retention", "Restriction applied instead of erasure (access limitation, minimised projection)", "Decision record with the deciding actor and instant" ] }, { "id": "q-retention-disposition-evidence", "text": "What evidence is produced when disposition is finally executed?", "kind": "provenance", "answer_data": [ "Disposition action performed", "Execution instant with explicit offset and executing actor", "Retained tombstone metadata and its scope", "Authorisation reference for the disposition" ] } ], "data_elements": [ { "id": "de-retention-period", "name": "Retention period", "description": "Duration for which the document must be retained, with its measurement basis.", "value_kind": "duration", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-010" ] }, { "id": "de-retention-trigger", "name": "Retention trigger event", "description": "Event from which the retention period is measured.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-storage-location", "name": "Storage location", "description": "Jurisdiction and system in which the document and its evidence are stored.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-legal-hold", "name": "Legal hold", "description": "A suspension of disposition with reason, placing authority and placement and release instants.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "de-disposition-record", "name": "Disposition record", "description": "Record of the executed disposition action with authorisation, actor and instant.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-personal-data-marker", "name": "Personal data marker", "description": "Marks elements carrying personal data so that minimised projections and access restrictions can be applied.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "art-retention-schedule-assignment", "name": "Retention schedule assignment", "description": "Assignment of a retention class to the document with period, trigger, computed disposition date, storage constraints and any active holds.", "media_or_form": [ "structured record", "schedule assignment entry" ], "serial": false, "identity_strategy": "Keyed by document authoritative identifier plus retention class identifier; schedule itself keyed by its registered class identifier.", "source_refs": [ "SRC-006", "SRC-010" ] }, { "id": "art-disposition-certificate", "name": "Disposition certificate", "description": "Evidence artefact recording that a lawful disposition was executed, naming the authorisation, action, executing actor, instant and retained tombstone metadata.", "media_or_form": [ "certificate record", "append-only log entry" ], "serial": true, "identity_strategy": "Keyed by document authoritative identifier plus disposition sequence number; retained after the document itself is destroyed.", "source_refs": [ "SRC-011", "SRC-010" ] } ], "inline_only_rationale": null } ] }, { "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.", "source_refs": [ "SRC-006", "SRC-010", "SRC-012", "SRC-011" ], "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.", "source_refs": [ "SRC-006", "SRC-010", "SRC-012", "SRC-014" ], "questions": [ { "id": "q-ownership-holder", "text": "Who owns this record, who holds it as custodian, and what does the custodian agreement permit?", "kind": "ownership", "answer_data": [ "Owning party reference", "Custodian party references and roles", "Permitted processing scope per custodian", "Agreement reference and effective period" ] }, { "id": "q-access-projections", "text": "Which role-scoped projections exist, and which elements does each include and exclude?", "kind": "access", "answer_data": [ "Projection identifier and target role", "Included element set", "Excluded element set with justification", "Approving authority for the projection" ] }, { "id": "q-access-authority-request", "text": "On what basis may a tax or judicial authority obtain access, and what is the response obligation?", "kind": "authority", "answer_data": [ "Legal basis for the access request", "Scope granted and its limits", "Response deadline", "Record of what was disclosed and to whom" ] }, { "id": "q-access-secondary-use", "text": "What secondary use of invoice content is permitted to a custodian, and what is prohibited?", "kind": "privacy", "answer_data": [ "Permitted secondary uses", "Prohibited uses and their basis", "Consent or contractual basis where required", "Enforcement and breach reporting path" ] } ], "data_elements": [ { "id": "de-owning-party", "name": "Owning party", "description": "Reference to the party that owns the record.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-010" ] }, { "id": "de-custodian-party", "name": "Custodian party", "description": "Reference to a party holding or processing the record on the owner's behalf, with its role.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-014" ] }, { "id": "de-projection-definition", "name": "Projection definition", "description": "Named role-scoped view listing included and excluded elements.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-disclosure-record", "name": "Disclosure record", "description": "Record of a disclosure to an authority or third party with basis, scope, recipient and instant.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-006" ] } ], "artifacts": [ { "id": "art-access-projection-set", "name": "Access projection set", "description": "Registered set of role-scoped projections over the document with their element inclusion and exclusion rules and approving authority, applied uniformly across every storage format and interface.", "media_or_form": [ "projection definition set", "structured policy record" ], "serial": false, "identity_strategy": "Keyed by projection identifier plus version; bound to the model identifier rather than to any single document.", "source_refs": [ "SRC-006", "SRC-012" ] } ], "inline_only_rationale": null }, { "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.", "source_refs": [ "SRC-011", "SRC-009", "SRC-012", "SRC-005" ], "questions": [ { "id": "q-provenance-actor-chain", "text": "Which parties and systems handled this document and in what order?", "kind": "provenance", "answer_data": [ "Ordered handling chain with party and system references", "Role of each handler", "Handover instants with explicit offsets", "Custody transfer evidence" ] }, { "id": "q-provenance-derivation", "text": "Which content was generated, derived or transformed rather than authored, and from what source?", "kind": "composition", "answer_data": [ "Derived element list", "Source of each derived value", "Transformation or generation rule identifier", "Digest of the input used" ] }, { "id": "q-provenance-time-separation", "text": "How are event times separated from observation and ingestion times where the two differ?", "kind": "temporal", "answer_data": [ "Event instant asserted by the acting system", "Observation or ingestion instant recorded by the receiving system", "Divergence magnitude and its explanation", "Clock source and synchronisation basis" ] }, { "id": "q-provenance-tamper-detection", "text": "How would an unauthorised change to the audit trail itself be detected?", "kind": "security", "answer_data": [ "Append-only or chained-digest control applied", "Verification procedure and last verification instant", "Independent copy or witness location", "Escalation on detected tampering" ] } ], "data_elements": [ { "id": "de-handling-event", "name": "Handling event", "description": "A recorded act on the document with type, acting party, acting system and event instant.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-012" ] }, { "id": "de-observation-instant", "name": "Observation instant", "description": "RFC 3339 instant at which a handling act was observed or ingested, distinct from the event instant.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-derivation-source", "name": "Derivation source", "description": "Reference to the input from which a derived value was produced, with the rule applied.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-trail-chain-digest", "name": "Audit trail chain digest", "description": "Digest chaining log entries so that removal or alteration of an entry is detectable.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "art-provenance-record", "name": "Provenance record", "description": "Chained, append-only record of every handling act with actor, system, event instant, observation instant, inputs and outputs, verifiable independently of the document store.", "media_or_form": [ "append-only chained log", "structured record set" ], "serial": true, "identity_strategy": "Keyed by document authoritative identifier plus entry sequence number, with each entry carrying the digest of the previous entry.", "source_refs": [ "SRC-011", "SRC-009" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "fn-issue-commercial-document", "name": "Issue commercial document", "description": "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.", "inputs": [ "Commercial inputs (order, contract, fulfilment records, priced lines)", "Party references for all required roles", "Governing jurisdiction and particulars profile", "Declared specification and profile identifiers" ], "outputs": [ "Issued billing document with authoritative identifier", "Immutability instant and content digest", "Lifecycle event recording issue" ], "preconditions": [ "Issuing authority established, including any self-billing or outsourcing mandate", "Number series available and its sequence rule known", "Required particulars for the governing jurisdiction determinable" ], "effects": [ "Document content becomes immutable; later change requires a new document", "Statutory issue-deadline clock is assessed against the chargeable event", "Retention trigger becomes computable" ], "source_refs": [ "SRC-010", "SRC-006", "SRC-004" ] }, { "id": "fn-compute-tax-and-totals", "name": "Compute tax breakdown and totals", "description": "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.", "inputs": [ "Invoice lines with tax category assignments", "Document-level allowances and charges", "Currency and precision rules", "Applicable tax rates and exemption reasons" ], "outputs": [ "Tax breakdown statement", "Stated totals including amount due", "Reconciliation expressions for each total" ], "preconditions": [ "Tax category and rate resolvable for every amount including allowances and charges", "Currency and any tax accounting currency determined" ], "effects": [ "All calculated values are present in the instance", "Arithmetic rule set becomes checkable by any receiver" ], "source_refs": [ "SRC-004", "SRC-002", "SRC-005" ] }, { "id": "fn-validate-against-profile", "name": "Validate against declared specification", "description": "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.", "inputs": [ "Document instance in a supported syntax", "Declared customization and profile identifiers", "Validation artefact set and version" ], "outputs": [ "Validation report with per-rule outcomes and severities", "Aggregate verdict", "List of rule sets deliberately not executed" ], "preconditions": [ "Artefact version resolvable from the registry", "Syntax binding recognised" ], "effects": [ "Conformance claim becomes evidenced rather than asserted", "Failing documents are routed to the exception path rather than transmitted" ], "source_refs": [ "SRC-005", "SRC-003", "SRC-004" ] }, { "id": "fn-clear-with-tax-authority", "name": "Register or clear with tax authority", "description": "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.", "inputs": [ "Issued document and its digest", "Regime identification and submission credentials", "Applicable deadline and trigger event" ], "outputs": [ "Clearance response record", "Authority-assigned identifier and acknowledgement instant", "Updated clearance status" ], "preconditions": [ "Regime applicability determined for the jurisdiction and document type", "Document conforms to the regime's required content" ], "effects": [ "Authority-assigned identifier becomes the master-system identifier for that jurisdiction", "Lawful delivery to the buyer becomes permitted where clearance is a precondition" ], "source_refs": [ "SRC-007", "SRC-006", "SRC-005" ] }, { "id": "fn-transmit-and-route", "name": "Transmit and route document", "description": "Discover the receiver's capability and endpoint, wrap the document in the network envelope, transmit under the agreed transport profile and retain delivery evidence.", "inputs": [ "Issued and validated document", "Receiver participant identifier", "Document type and process identifiers" ], "outputs": [ "Transmission record with routing identifiers and outcome", "Transport receipt reference and instant", "Failure reason where delivery did not succeed" ], "preconditions": [ "Receiver capability for the document type confirmed by metadata lookup", "Transport profile and security requirements satisfied" ], "effects": [ "Delivery evidence exists, distinct from business acceptance", "Retry or fallback path is triggered on failure" ], "source_refs": [ "SRC-012", "SRC-003", "SRC-014" ] }, { "id": "fn-verify-authenticity-and-integrity", "name": "Verify authenticity and integrity", "description": "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.", "inputs": [ "Document instance and its recorded digest", "Declared assurance method and any signature or token", "Audit trail links to the underlying supply" ], "outputs": [ "Verification outcome with verifying actor and instant", "Identified unprotected scope", "Quarantine decision on mismatch" ], "preconditions": [ "Digest recorded at ingestion is available", "Assurance method and its parameters are known" ], "effects": [ "A verified document may be relied on as evidence", "A mismatch quarantines the artefact and blocks disposition" ], "source_refs": [ "SRC-011", "SRC-010", "SRC-013" ] }, { "id": "fn-match-to-order-and-receipt", "name": "Match to order and receipt", "description": "Reconcile the document and its lines against referenced order and goods receipt records within declared tolerances to support an acceptance decision.", "inputs": [ "Document lines and their references", "Referenced order and receipt records", "Tolerance policy" ], "outputs": [ "Matching result record with per-line outcomes", "Unmatched and unresolvable reference lists", "Recommended acceptance decision" ], "preconditions": [ "References resolvable to accessible records", "Matching mode selected (two-way, three-way, line-level)" ], "effects": [ "Acceptance or rejection decision becomes evidenced", "Unresolvable references are escalated rather than silently ignored" ], "source_refs": [ "SRC-004", "SRC-001", "SRC-008" ] }, { "id": "fn-record-buyer-response", "name": "Record buyer response", "description": "Capture the receiver's business response — acknowledgement, acceptance, conditional acceptance, rejection or dispute — with coded reasons and the authorising role.", "inputs": [ "Received document identifier", "Response kind and coded reasons", "Responding party and authorising role" ], "outputs": [ "Business response message", "Updated lifecycle state", "Dispute state where applicable" ], "preconditions": [ "Responder authorised within their limits", "Response window still open where one applies" ], "effects": [ "Business acceptance is recorded separately from transport receipt", "A dispute suspends practical payment expectation without altering the document" ], "source_refs": [ "SRC-012", "SRC-003", "SRC-006" ] }, { "id": "fn-issue-correction-or-credit", "name": "Issue correction or credit", "description": "Amend an issued document by producing a new document that refers specifically and unambiguously to it, using the mechanism lawful in the governing jurisdiction.", "inputs": [ "Original document identifier and issue date", "Correction scope, including affected lines", "Governing jurisdiction and permitted mechanism" ], "outputs": [ "New billing document with preceding-document reference", "Updated correction chain graph", "Recomputed net claim amount" ], "preconditions": [ "Original document retrievable and its digest recorded", "Chosen mechanism lawful for the document type and jurisdiction" ], "effects": [ "The original remains unmodified and retrievable", "The commercial claim is changed only through the chain, never by editing" ], "source_refs": [ "SRC-010", "SRC-004", "SRC-006" ] }, { "id": "fn-render-human-readable", "name": "Render human-readable form", "description": "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.", "inputs": [ "Structured document instance", "Rendition format and preservation profile", "Precedence declaration between representations" ], "outputs": [ "Human-readable rendition or hybrid carrier", "Divergence report between representations", "Legibility check outcome" ], "preconditions": [ "Required particulars available for display", "Preservation profile supported by the rendering toolchain" ], "effects": [ "Legibility obligation for the storage period becomes demonstrable", "Divergence between visual and structured forms is detected rather than latent" ], "source_refs": [ "SRC-013", "SRC-011", "SRC-006" ] }, { "id": "fn-apply-retention-and-disposition", "name": "Apply retention and disposition", "description": "Assign the retention class, compute the earliest disposition date, honour holds and, when eligible, execute disposition with evidence.", "inputs": [ "Retention trigger event and jurisdiction", "Retention schedule and class", "Active legal holds and dispute states" ], "outputs": [ "Retention schedule assignment", "Disposition eligibility determination", "Disposition certificate on execution" ], "preconditions": [ "Retention period and trigger determined for the governing jurisdiction", "No active hold or unresolved dispute in scope" ], "effects": [ "Records are not destroyed while under hold or dispute", "Disposition leaves auditable tombstone evidence after the record is gone" ], "source_refs": [ "SRC-006", "SRC-010", "SRC-011" ] }, { "id": "fn-project-role-scoped-view", "name": "Project role-scoped view", "description": "Produce the projection appropriate to a requesting role — routing metadata, evidentiary set, authority disclosure, minimised personal-data view — and record the disclosure.", "inputs": [ "Requesting role and legal or contractual basis", "Projection definition and version", "Document and its evidence set" ], "outputs": [ "Role-scoped projection", "Disclosure record with recipient, scope and instant", "Denial reason where the request is refused" ], "preconditions": [ "Projection registered and approved", "Requester authenticated and their basis established" ], "effects": [ "Access is granted by projection rather than by ad hoc field hiding", "Every disclosure is auditable and attributable" ], "source_refs": [ "SRC-006", "SRC-010", "SRC-012" ] }, { "id": "fn-issue-self-billed-invoice", "name": "Issue self-billed invoice", "description": "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.", "inputs": [ "self-billing agreement reference", "supplier and customer party identities", "billed supply data" ], "outputs": [ "self-billed invoice carrying the 'Self-billing' mention", "supplier acceptance status or dispute notice" ], "preconditions": [ "a self-billing agreement authorises the customer to issue in the supplier's name" ], "effects": [ "the issuer role is inverted to the customer while the supply stays the supplier's", "supplier reconciliation outcome is captured, including a self-billing credit note where needed" ], "source_refs": [ "SRC-015", "SRC-022", "SRC-019" ] }, { "id": "fn-present-payment-claim", "name": "Present payment claim", "description": "Expose payable amount, due date or terms, payment means and payee so a payment process can settle the invoice without storing the payment here.", "inputs": [ "amount due for payment", "payment due date or payment terms", "payment means and payee financial account" ], "outputs": [ "payment claim presentation for a settlement process" ], "preconditions": [ "the amount due for payment is positive", "either a payment due date or payment terms is present" ], "effects": [ "settlement can be initiated in WM-ECO-009 without storing payment execution records on the invoice" ], "source_refs": [ "SRC-016", "SRC-015" ] } ], "composition": [ { "target": "WM-ECO-009 Payment / Settlement", "relation": "REFERENCE", "purpose": "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.", "required": true, "source_refs": [ "SRC-004", "SRC-003", "SRC-006" ] }, { "target": "WM-ECO-024 Order Fulfilment", "relation": "REFERENCE", "purpose": "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.", "required": false, "source_refs": [ "SRC-004", "SRC-011" ] }, { "target": "Document & Record (legacy N1 recordkeeping model)", "relation": "EXTEND", "purpose": "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.", "required": false, "source_refs": [ "SRC-010", "SRC-006", "SRC-011" ] }, { "target": "Organization / Legal Entity", "relation": "REFERENCE", "purpose": "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.", "required": true, "source_refs": [ "SRC-004", "SRC-008" ] }, { "target": "Person / Contact", "relation": "REFERENCE", "purpose": "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.", "required": false, "source_refs": [ "SRC-001", "SRC-004" ] }, { "target": "Product / Item and Classification", "relation": "REFERENCE", "purpose": "Line items reference item records and classification schemes; the invoice carries identifiers and a descriptive snapshot rather than governing item master data.", "required": false, "source_refs": [ "SRC-001", "SRC-004" ] }, { "target": "Order and Contract", "relation": "REFERENCE", "purpose": "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.", "required": false, "source_refs": [ "SRC-008", "SRC-004" ] }, { "target": "Tax Registration and Rate", "relation": "REFERENCE", "purpose": "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.", "required": true, "source_refs": [ "SRC-005", "SRC-006" ] }, { "target": "Identifier Scheme Registry", "relation": "REFERENCE", "purpose": "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.", "required": true, "source_refs": [ "SRC-005", "SRC-012" ] }, { "target": "Currency and Unit of Measure code lists", "relation": "ALIGN", "purpose": "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.", "required": true, "source_refs": [ "SRC-005", "SRC-004" ] }, { "target": "European semantic model of the core elements of an electronic invoice (EN 16931 family)", "relation": "ALIGN", "purpose": "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.", "required": false, "source_refs": [ "SRC-005", "SRC-008", "SRC-003" ] }, { "target": "Invoice syntaxes (business-language XML, cross-industry XML, hybrid carriers)", "relation": "ALIGN", "purpose": "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.", "required": false, "source_refs": [ "SRC-001", "SRC-002", "SRC-013" ] }, { "target": "Four-corner exchange network", "relation": "REFERENCE", "purpose": "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.", "required": false, "source_refs": [ "SRC-012", "SRC-003", "SRC-014" ] }, { "target": "Attachment / Binary Object", "relation": "COMPOSE", "purpose": "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.", "required": false, "source_refs": [ "SRC-004", "SRC-013" ] }, { "target": "Accounting Ledger / Journal Entry", "relation": "REFERENCE", "purpose": "Postings derived from the invoice are referenced for traceability; presentation differences in the ledger do not invalidate the document and are not modelled here.", "required": false, "source_refs": [ "SRC-006", "SRC-004" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "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.", "The owner package must declare, per jurisdiction it operates in, the applicable particulars profile, the retention period and trigger, whether a clearance or reporting regime applies, and the accepted usage specifications, with the legal basis cited for each.", "The owner package must pin code-list and validation-artefact versions and subscribe to the publishing release cycle, so that a document can always be revalidated against the artefact version in force at issue as well as the current one.", "The owner package must define role-scoped projections before granting any access, and must operate an append-only provenance log that is verifiable independently of the document store.", "The owner package must publish an AGENTS.md bootstrap contract at the root of whatever storage the model is projected into, regardless of whether that storage is a file tree, a document database or an MCP-exposed service." ], "namespace_guidance": "Use a stable, storage-neutral namespace of the form .commercialDocument.., for example world.commercialDocument.identityAndClassification.identityAndNumbering. Namespace segments are lower camel case, never versioned in the path, and never derived from a date or a syntax name; syntax bindings (business-language XML, cross-industry XML, hybrid carriers, JSON, Markdown, Git, MCP, MongoDB) are projections addressed by mapping manifest rather than by namespace. Jurisdictional variants are expressed as usage-specification identifiers attached to instances, not as forked namespaces, so that a single semantic namespace serves all regions.", "registry_links": [ "vr.wm-eco-008 — this registry entry, nav path NAV.SOC.ECO.INV, domain tags SOC.ECO.INV, legacy alias N1", "Registry of supporting artefacts for the European invoice standard: validation artefacts, code lists and registered usage specifications and extensions (SRC-005)", "Registered usage specification and profile identifiers published by the exchange network operator (SRC-003, SRC-012)", "Scheme registries for party identifiers and electronic addresses referenced by the identifier priority (SRC-005, SRC-012)", "planning/VERCY-MODEL-RELATIONS.csv — typed edges to WM-ECO-009 and WM-ECO-024 recorded in the relations register" ] }, "canon_and_patch": { "canonicalization_rules": [ "Canonical form is semantic, not syntactic: the canonical record is the set of model data elements with their values, independent of whether the instance is carried as business-language XML, cross-industry XML, a hybrid carrier, JSON or database documents.", "Amounts are normalised to the decimal precision required by the document currency with the declared rounding mode, and every calculated value is materialised explicitly; no value may be omitted on the assumption that a receiver will recompute it.", "Codes are stored with their code-list identifier and version and are compared case-insensitively but stored as published; unversioned code references are rejected at canonicalisation.", "Instants are normalised to RFC 3339 with seconds and an explicit offset or Z; date-only business terms remain calendar dates and carry their governing jurisdiction rather than being widened into instants.", "Text is normalised to Unicode NFC with trailing whitespace trimmed; collections are ordered deterministically (lines by line identifier, tax groups by category code then rate) before any digest is computed.", "The integrity digest is computed over the canonical business document only and explicitly excludes the transport envelope, routing metadata and any post-receipt annotation." ], "patch_rules": [ "An issued document is immutable. There is no patch operation on issued content; commercial change is expressed only by issuing a further document that refers specifically and unambiguously to the original.", "Annotation planes — lifecycle state, validation results, matching results, responses, transmission records, provenance entries, retention assignment — are append-only. Entries are added, never edited or removed, and each carries actor, acting system and an RFC 3339 instant with explicit offset.", "A correction to an annotation is a new entry that supersedes an earlier one by reference; the superseded entry remains retrievable.", "No patch may alter a document that has been cleared or registered by an authority, nor any bytes covered by a signature, seal or clearance token; such a change invalidates the assurance and must instead trigger the correction mechanism.", "Pre-issue drafts may be edited freely but are marked non-fiscal, are excluded from retention and clearance obligations, and must not be exposed through any projection that implies issued status." ], "compatibility_rules": [ "Adding an optional data element or an additional annotation plane is a minor, backward-compatible change; consumers must ignore unknown optional content rather than reject it.", "Tightening cardinality, removing an element, changing a value kind or narrowing a code list is breaking and requires a major revision plus a migration note naming affected instances.", "A usage specification may restrict the model but must not change the meaning of a core element; an extension may add content but must not make core content unreadable to a core-only consumer.", "Code-list and validation-artefact versions are pinned per instance. A document remains interpretable against the artefact version in force at issue; revalidation against a newer version is recorded as a separate result and does not retroactively invalidate the original verdict.", "Conformance to the core rule set does not imply conformance to a network's additional rules; each claim names its rule set explicitly and is evidenced separately." ] }, "artifact_rules": { "identity_priority": [ "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." ], "timestamp_rule": "All instant-valued fields use RFC 3339 date-time with explicit seconds and an explicit numeric UTC offset or Z; where UTC is known but the local offset is not, -00:00 is used rather than Z. Event time (issue, signature, clearance acknowledgement, despatch, response, disposition) is recorded separately from observation or ingestion time (receipt at an access point, ingestion into a store, validation execution, archiving) whenever the two differ, and both are retained with the acting system and its clock source. Date-only business terms such as the issue date, tax point date and due date remain calendar dates carrying their governing jurisdiction and must never be silently widened into timestamps by assuming a time zone.", "serial_naming_rule": "Serial artefacts — invoice numbers, clearance responses, validation reports, matching runs, transmission records, provenance entries, disposition certificates — are named ----, where serialKey preserves the originating system's own monotonic sequence. Sequence gaps must be explainable from the record itself; no date component is used as the sort key or as part of the key; a re-issued, replaced or corrected artefact takes a new serialKey and records a supersession link rather than reusing or overwriting an existing key.", "integrity_rule": "Every stored artefact carries a cryptographic digest (SHA-256 or stronger) over its canonical byte form together with the algorithm identifier, computed on the business document excluding the transport envelope. The digest is recorded at ingestion with the observing actor and instant, and every signature, seal, clearance token or timestamp is bound to that digest and to a stated covered scope. Attachments carry their own digests and are only treated as protected if they fall inside a declared signature scope. A digest mismatch quarantines the artefact, blocks disposition and raises an integrity exception; long-lived artefacts are re-protected before the underlying algorithms or certificates expire." }, "policies": [ "Technology neutrality on assurance: the model must not require electronic signatures. Business controls creating a reliable audit trail between the invoice and the supply are an accepted method in the governing law, and a Dimension asserting that signatures are mandatory must cite the specific jurisdictional rule that makes them so.", "Immutability after issue: no process, integration or repair job may edit issued content. Data-quality defects in an issued document are corrected through the lawful correction mechanism, and any tooling capable of in-place edit must be disabled for issued records.", "Jurisdiction is explicit: every conformance, retention, particulars and clearance statement names the jurisdiction it applies to. Unqualified statements such as 'compliant' or 'retained for the required period' are rejected at review.", "Transport receipt is never recorded as business acceptance, and business acceptance is never inferred from silence unless a named rule establishes that inference.", "Personal data on invoices is marked, minimised in projections and restricted rather than erased where a statutory retention obligation applies; the conflict is recorded as a decision with its legal basis, never resolved silently.", "Evidence over assertion: conformance, integrity, delivery and disposition claims are only valid where the corresponding artefact (validation report, integrity evidence set, transmission record, disposition certificate) exists and is retrievable.", "Issued invoices are not updated in place; use credit notes, corrected invoices or negative-amount invoices.", "Invoice numbers must be unique within the seller series and uniqueness window; dates are not identifiers.", "Access defaults to parties on the invoice, their authorised agents and competent tax or customs authorities; other access is exception-based and audited.", "Retention, legal holds and destruction of the invoice-as-record are executed through N1 using tax and customs minimum-retention overlays, not by deleting the commercial claim silently." ], "crud": { "read": [ "Read is always through a registered role-scoped projection; the full record is available only to the owner, to authorised custodians within their agreed scope, and to authorities on a stated legal basis.", "Reads that disclose content outside the owning organisation produce a disclosure record with recipient, scope, basis and instant.", "Historical reads must be able to return the document as it stood at issue, including the artefact and code-list versions then in force." ], "create": [ "Creation requires the governing jurisdiction, particulars profile, declared specification and issuing authority to be resolved first; a document may not be created and classified afterwards.", "On issue the system assigns the identifier from the correct series, computes and stores the content digest, records the immutability instant and emits a lifecycle event.", "Where a clearance regime applies, creation is not complete until the authority response is captured and bound to the digest, or the failure path is recorded." ], "update": [ "Issued content is never updated. Update applies only to append-only annotation planes and to pre-issue drafts.", "Annotation updates are additive entries carrying actor, acting system and an RFC 3339 instant with explicit offset; superseding an earlier entry requires an explicit supersession reference.", "Any attempt to update issued content is rejected, logged as an integrity exception and surfaced to the owner." ], "delete": [ "Deletion is only permitted as disposition after the retention period has elapsed, with no active legal hold, dispute or clearance-related obligation in scope.", "Disposition requires an authorisation reference and produces a disposition certificate that survives the record, retaining identity, class, dates and the authorisation but not content.", "Erasure requests for personal data on retained invoices are answered by restriction and minimised projection, with the decision, legal basis, deciding actor and instant recorded." ] }, "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" ] } ], "access": { "default_rule": "Deny by default. Access is granted only through a registered, approved role-scoped projection bound to a named role and a stated legal or contractual basis; no principal receives the full record implicitly, and every grant is time-bounded and revocable.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Tax and judicial authorities may obtain access on a stated legal basis without owner consent, within the scope of the request; the disclosure is still recorded.", "An exchange service provider is granted envelope and routing metadata plus whatever payload access the transport requires, but not analytical or secondary-use access to content.", "An auditor is granted the evidentiary projection covering the correction chain, integrity evidence and provenance for a defined engagement period, without write access.", "Documents under legal hold are readable by hold-scoped roles even where a retention-based access restriction would otherwise have narrowed access.", "Emergency break-glass access is permitted only with a named approver, a stated reason, an automatic expiry and a mandatory post-hoc review.", "Legal hold or audit may extend read access to regulators and courts without granting update rights", "Factoring assignment may redirect payee-visible payment instructions without exposing unrelated line detail beyond what the assignment requires", "Public e-invoicing clearance systems may be given a mandated reporting projection that is not full evidentiary content" ], "audit_requirements": [ "Every read that crosses an organisational boundary produces a disclosure record with recipient, projection identifier, scope, basis and RFC 3339 instant with explicit offset.", "Every write to an annotation plane records actor, acting system, event instant and observation instant where they differ.", "Break-glass access, hold placement and release, and disposition execution each require an approver reference and are reviewed after the fact.", "The provenance log is chained so that removal or alteration of an entry is detectable, and is verified on a defined schedule with the verification instant retained.", "Audit records are retained at least as long as the documents they describe, and disposition certificates are retained beyond the destruction of the record itself.", "Record who read or exported invoice content versus metadata, with observation time in RFC 3339", "Record issue, send, validation, credit, correction and access-exception events with actor and event time", "Retain validation reports with the issued instance for tax audit" ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID", "Registry ID" ], "read_order": [ "AGENTS.md at the root of the storage projection — establishes Name, Type, Specification URL, Storage type URL, Interface URL and Processes URL before any other access, including for MongoDB collections and MCP-exposed services where it is published as a discoverable bootstrap document.", "Specification URL — the format-neutral model definition: bundles, layers, findings, questions, data elements and identity priority.", "Storage type URL — how the model is projected into the concrete store, including canonical form, digest computation and the mapping manifest for each syntax.", "Interface URL — the access surface, registered projections, scopes and the deny-by-default rule.", "Processes URL — the functions, their preconditions and effects, and the exception paths for validation failure, clearance failure, dispute and disposition.", "Registry entry vr.wm-eco-008 and the relations register — to resolve sibling models before creating any typed edge." ] } }, "coverage": { "claim": "Merged model covers the commercial billing document as a governed aggregate: identity, typing and specification claim; issuance authority and legally distinct dates; parties, priced lines, allowances and charges; tax breakdown, currency and constrained totals; payment instruction; commercial and correction references; attachments and renditions; lifecycle, buyer response, authenticity and clearance; regulatory conformance evidence; and exchange, retention, access and provenance. Evidence is strongest for EU/EN 16931/Peppol/UBL semantics and EU VAT law, with UN/CEFACT CII process material added for self-billing, prepayment and special billing variants. Coverage is jurisdiction-qualified and explicitly not universal: customs valuation invoices, national CTC profiles, receivables financing and non-EU mandatory-particulars overlays are outside the accepted boundary or recorded as gaps.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Identity is scoped as issuer party identifier plus invoice number plus document type, with the authority-assigned clearance identifier taking precedence where a clearance regime applies, and surrogates confined to internal use. The requirement for a sequential number and the negative rule that dates and file names are not identifiers are both stated." }, { "dimension": "lifecycle", "status": "covered", "notes": "State set, permitted transitions, the immutability point at issue, the inserted clearance state, buyer response and dispute, and the correction chain as the lawful substitute for editing are all modelled, with transitions recorded as append-only events." }, { "dimension": "relationships", "status": "covered", "notes": "Typed references to order, contract, despatch and receiving advice, tender, project and preceding documents; the correction chain graph; and composition links to payment, fulfilment, party, item and identifier-scheme models, each with a stated boundary." }, { "dimension": "temporal", "status": "covered", "notes": "Issue, tax point, delivery and period dates are separated by legal effect; issue and clearance deadlines are assessed; RFC 3339 with seconds and explicit offset governs instants; event time is separated from observation or ingestion time; date-only terms are protected from silent widening." }, { "dimension": "provenance", "status": "covered", "notes": "A chained append-only provenance record covers generation, transformation, signing, clearance, transmission, validation, storage, disclosure and disposition, with derivation sources and tamper detection." }, { "dimension": "ownership", "status": "covered", "notes": "The issuing organisation owns the record; custodians hold it without acquiring ownership; issuance may be outsourced or self-billed under an evidenced mandate while responsibility is retained." }, { "dimension": "validation", "status": "covered", "notes": "Versioned schema and business rule execution with retained per-rule outcomes, severity, aggregate verdict and rule-set identity; explicit warning that core conformance does not imply network conformance; revalidation on artefact release cycles." }, { "dimension": "access", "status": "covered", "notes": "Deny by default with registered role-scoped projections at bundle, layer, finding and artefact scope; named exceptions for authorities, service providers, auditors, holds and break-glass; disclosure records for boundary-crossing reads." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention period and trigger set by jurisdiction; preservation of authenticity, integrity and legibility for the whole period; holds suspend disposition without altering content; disposition produces a surviving certificate; the erasure-versus-retention conflict is modelled as a recorded decision rather than a silent choice." }, { "dimension": "interoperability", "status": "covered", "notes": "Syntax bindings treated as projections with a mapping manifest and measured round-trip fidelity; usage specifications and extensions distinguished; code-list versions pinned; routing identifiers, discovery, envelope and transport separated from document semantics." }, { "dimension": "tax and regulatory conformance", "status": "covered", "notes": "Jurisdiction-qualified particulars matrix, conditional requirements for exemption, reverse charge and self-billing, national usage specifications, language and translation obligations." }, { "dimension": "monetary integrity", "status": "covered", "notes": "Constrained arithmetic across lines, allowances, charges, tax groups and totals, with explicit materialisation of calculated values, rounding rules and a reconciliation report artefact." }, { "dimension": "correction and cancellation", "status": "covered", "notes": "Preceding-document reference, jurisdiction-dependent mechanism choice, immutability of the original and net-claim computation across the chain." }, { "dimension": "human readability", "status": "covered", "notes": "Hybrid carriers, precedence between visual and structured representations, divergence detection and legibility maintenance across the storage period." }, { "dimension": "security", "status": "covered", "notes": "Digest and signature scope, unprotected-content identification, long-term re-protection, chained audit log and quarantine on mismatch; assurance method treated as elective where the law permits business controls." }, { "dimension": "measurement", "status": "covered", "notes": "Quantities with versioned unit codes, base quantity for pricing, tolerances in matching and reconciliation, and fidelity measurement for syntax transformation." }, { "dimension": "consumer and receipt semantics", "status": "not-applicable", "notes": "Point-of-sale fiscal receipts and cash-register fiscalisation are excluded by scope; the European core invoice semantics consulted here are not designed for consumer invoicing, so extending the model to receipts without separate sources would be unsupported." }, { "dimension": "financing and assignment", "status": "gap", "notes": "Receivables financing, factoring and assignment of the invoice claim are recognised as real operating surface but no primary source was consulted for them; an ISO 20022 trade-services fetch timed out. Treated as a gap, not modelled as canonical." } ], "known_omissions": [ "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." ], "conflicts": [ "Sequential numbering versus opaque identifiers: the legal requirement for a sequential number that uniquely identifies the invoice conflicts with the common engineering preference for UUIDs. Resolved here by ranking the issuer's sequential number above surrogates and forbidding surrogates from being presented as the legal number — but a Dimension using UUIDs as invoice numbers may be non-compliant in some jurisdictions.", "Date-only business terms versus instant-valued timestamps: the invoice issue date, tax point date and due date are calendar dates in the core semantic model, while the protocol requires RFC 3339 instants with offsets. Widening a date to an instant invents a time zone and can shift the date across a boundary. Resolved by keeping dates as dates with a governing jurisdiction and confining RFC 3339 to system-observed instants.", "Clearance identifier versus issuer number: under continuous transaction control regimes the authority-assigned identifier is the legally operative one, but most syntaxes and integrations key on the issuer's number. The two-tier identity priority resolves this, but tooling built on the issuer number alone will be wrong in those jurisdictions.", "Recipient acceptance of electronic invoices: the long-standing rule that use of an electronic invoice is subject to the recipient's acceptance is being displaced by mandatory domestic e-invoicing regimes and by the digital-age package from its entry into force. Both states exist in practice during the transition.", "Core conformance versus network conformance: a document can satisfy the core European rule set and still be rejected by a network that layers additional rules on top. Claiming a single undifferentiated 'compliant' status is unsafe.", "Hybrid carriers with two representations: a single file carrying both a visual rendition and embedded structured data can hold divergent content, and which representation prevails is not uniform across jurisdictions.", "Statutory retention versus personal-data erasure: an erasure request cannot override a statutory retention obligation, but neither can the obligation be used to justify unlimited processing. Modelled as restriction plus a recorded decision rather than as a resolved rule.", "Syntax round-tripping: business-language XML and cross-industry XML bindings are not bijective; a transformation chain can silently lose extension content. Fidelity must be measured, not assumed.", "Legacy model boundary: the registry entry still carries the legacy alias and a generic document-and-record specification reference, and its parent identifier is empty while a validation flag suggests it could be a child of that model. The parent relationship is therefore unresolved.", "UBL Invoice means a request for payment; 19 CFR 141.86 commercial invoice is a customs valuation document and may exist without a payment claim.", "Peppol and EN 16931 use date-only YYYY-MM-DD for issue/due/tax point; this model's operational timestamps require RFC 3339 instants with seconds and offset.", "A CIUS-only receiver may reject a CORE invoice that uses options restricted out of that CIUS, even though CORE receivers must accept any compliant CIUS.", "Credit may be a 381 credit note with positive amounts or a 380 invoice with negative amounts; these are alternative processes, not one canonical encoding.", "UBL 2.4 is the current OASIS Standard, while EN 16931 syntax bindings in production commonly still target UBL 2.1 and CII D16B.", "Self-billing inverts the UBL submitter role; VAT identity of the supply remains the supplier's.", "Proforma invoice (325) shares structure with a commercial invoice but must not be treated as a legally issued payment claim." ], "regional_assumptions": [ "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." ], "adversarial_checks": [ "Tested whether electronic signatures are a normative requirement for invoice integrity. They are not: the governing guidance treats business controls creating a reliable audit trail as sufficient and names signatures and EDI as examples. A structure that made signatures mandatory would have been attractive and wrong, so the model records assurance method as elective and jurisdiction-qualified.", "Tested whether the legacy generic version-chain pattern should be carried over from the previous-version material. It should not: an issued invoice is immutable and is amended by a further document, so applying a version chain to invoice content would model an unlawful operation. The correction chain replaces it and the conflict with the parent model is recorded.", "Tested whether transport-level receipt can stand in for business acceptance. It cannot; the network specifications distinguish message-level status from business response, so the model keeps delivery evidence and business response as separate findings with separate artefacts.", "Tested whether the issuer's invoice number can be treated as the authoritative identifier everywhere. It cannot, because clearance regimes assign an identifier that is legally operative; the identity priority therefore leads with the authoritative master-system identifier defined by regime, not with the issuer's number.", "Tested whether a single 'compliant' or 'valid' flag is defensible. It is not, because usage specifications and networks layer additional rules on the core set and artefact versions change on a release cycle; the model requires rule-set identity and artefact version to accompany every verdict.", "Tested whether settlement status belongs on the invoice. It does not; the document asserts an amount due at issue, and holding a mutable paid or unpaid field on an immutable record would corrupt both the record and the settlement model. Settlement is referenced and derived instead.", "Tested whether date-only business terms could simply be stored as RFC 3339 instants for uniformity. They cannot without inventing a time zone and risking a date shift across offsets, which would change tax point and deadline assessments; the timestamp rule therefore separates calendar dates from system-observed instants.", "Searched for a counterexample to the four-corner exchange assumption and found that a major economy operates no mandate and a voluntary network, which is why regional generalisation is recorded as an assumption rather than as structure.", "Could this model collapse into N1 Document & Record? No: lines, tax totals, payable amount, type codes and customs valuation are commercial-claim semantics; N1 is referenced for recordkeeping only.", "Are payments in scope? Only instructions, prepaid amount and typed settlement links; payment execution is WM-ECO-009.", "Is a customs commercial invoice the same object as a Peppol tax invoice? No; legal class and mandatory content differ and are explicit.", "Can an issued invoice be patched? Not in this model; successors carry corrections.", "Does alignment to UBL imply XML storage? No; UBL is a business-object alignment independent of XML, JSON, PDF, Git, MCP or MongoDB." ] }, "researchAdjudication": { "boundaryDecision": { "entry_kind": "aggregate", "status": "accepted", "rationale": "Accept the base boundary and its aggregate entry kind. The invoice is a composite consistency boundary — lines, allowances, tax breakdown groups and totals have no identity outside the document, and the family (invoice, credit note, debit note, self-billed, corrective) shares one governed structure — so 'aggregate' fits better than grok's 'entity'. The base boundary is also the cleaner one: it delegates generic recordkeeping to the record model, settlement to WM-ECO-009, fulfilment events to WM-ECO-024, and tax reporting to the return/DRR surface, and it excludes customs valuation invoices. Grok simultaneously placed the 19 CFR 141.86 customs commercial invoice in scope and asserted in its own adversarial check that it is a different legal act with different mandatory content; that internal tension is resolved by keeping customs valuation out and deferring it to a sibling trade-document entry rather than splitting this model." }, "decisions": [ { "concept": "Base provider selection", "disposition": "claude as base", "rationale": "Not chosen on size. The base states eleven explicit out-of-scope items and seven neighbour boundary notes with distinctions and source refs, and each governance surface (retention, access, provenance, authenticity, clearance, exchange) has a named home. Grok's boundary is internally inconsistent on customs invoices, which is the decisive difference." }, { "concept": "Entry kind aggregate versus entity", "disposition": "aggregate accepted", "rationale": "Lines, allowances, tax breakdown groups and totals have no independent identity or lifecycle outside the document, and the model governs a document family under one consistency boundary; entity would understate the composition and invite line-level records to be governed separately." }, { "concept": "Customs commercial invoice contents (19 CFR 141.86)", "disposition": "deferred to sibling trade-document entry", "rationale": "Evidence-backed in grok but does not fit any base layer: it is valuation for duties, not a VAT payment claim, with a different mandatory-content profile, in-transit resale documents and a named responsible exporter employee. Folding it into a billing aggregate would collapse two legal acts the sources keep apart." }, { "concept": "Self-billing, prepayment and special billing processes", "disposition": "accepted into lyr-lifecycle-and-response", "rationale": "The only grok-only finding that is both materially missing and squarely inside the base boundary; it adds the self-billing process flow with supplier dispute, prepayment absorption into a final invoice, and the consolidated/consignment/factored/freight variants the base does not name." }, { "concept": "Grok party, identifier and VAT-endpoint findings", "disposition": "rejected as duplicative", "rationale": "The base party finding already asks about role set, scheme-qualified identifiers, establishment and address effects on tax treatment, and routing address versus legal identity; adding seller-buyer-and-role-set and party-tax-and-electronic-ids would split one governed concern across two findings for BT-level detail only." }, { "concept": "Grok monetary totals and currency finding", "disposition": "rejected as duplicative", "rationale": "The base separates fnd-currency-and-conversion from fnd-totals-rounding-and-arithmetic-consistency and already requires every calculated value to be materialised and reconciled; grok's BR-CO-16 formula and two-decimal rule are instances of that constraint, not new structure." }, { "concept": "Positive price with negative quantity when crediting", "disposition": "rejected as a finding; retained as an encoding conflict", "rationale": "A real Peppol rule with no home at finding granularity in the base. It belongs as a question under the existing correction-chain finding, so it is recorded as an unresolved encoding alternative rather than added as duplicate structure." }, { "concept": "Grok billing-lifecycle-and-corrections finding", "disposition": "rejected as duplicative", "rationale": "The base already splits this into lifecycle states and immutability point, buyer response and dispute, and the preceding-document correction chain, each with its own artefact. The 381 versus negative-380 versus 384 choice is carried instead as a recorded conflict on mechanism selection." }, { "concept": "Grok compliance-validation-and-syntax finding", "disposition": "rejected as duplicative", "rationale": "Covered across the base specification-claim, validation-evidence and syntax-binding findings, which already warn that core conformance does not imply network conformance. The CIUS asymmetry — a CIUS-only receiver may reject a CORE instance that a CORE receiver must accept — is retained as a conflict note, not new structure." }, { "concept": "EN 16931 delivery information group (BG-13)", "disposition": "rejected as distributed coverage", "rationale": "Deliver-to party sits in the base party finding, actual delivery date and invoicing period in the issuance-dates finding, and despatch/receipt references in the commercial references finding. Adding grok's delivery block would duplicate three findings to gain a grouping label." }, { "concept": "Claude-only governance layers (retention, access, provenance, exchange)", "disposition": "retained", "rationale": "Grok delegates all of these to N1 Document & Record. The base retains only invoice-specific obligations — storage period fixed by national law, legibility for the whole period, authority access, delivery evidence versus business acceptance — and its scope statement already delegates generic recordkeeping machinery, so the delegation boundary is preserved." }, { "concept": "Date-only business terms versus RFC 3339 instants", "disposition": "accepted as agreed modelling rule", "rationale": "Both providers independently reached the same resolution: issue date, tax point and due date stay calendar dates with a governing jurisdiction, while system-observed instants use RFC 3339 with offset. Concordance across independent research raises this from open conflict to a stated rule." }, { "concept": "National continuous transaction control regimes", "disposition": "generic clearance retained, national profiles deferred", "rationale": "The base models clearance as an optional inserted lifecycle state with an authority-assigned identifier that outranks the issuer number, which is the transferable structure; SdI, IRN, NF-e, CFDI and PDP specifics were not researched by either provider and must not be invented." } ], "publicationHolds": [ "Source and live-version verification is unmet: the two providers share zero common source URLs even where they cite the same standards, so every accepted base URL and the borrowed grok UN/CEFACT sources must be fetched and re-pinned before publication (Peppol BIS Billing 3.0 May 2026 release, EN 16931 supporting artefacts v1.3.16, EAS v16.0, VATEX v8.0, UBL 2.1/2.4 canonical paths, Factur-X 1.09.2 / ZUGFeRD 2.5.2).", "Grok grounds Article 226 content on a legislation.gov.uk retained-EU-law mirror rather than the EUR-Lex consolidated Directive 2006/112/EC; any article-level mandatory-particulars claim carried into the merged model must be re-grounded on the EU consolidated text, since a retained-law mirror can diverge from current EU law.", "Neither provider read the normative EN 16931-1 text (paywalled catalogue), so all BT/BG term-level semantics are second-hand via usage specifications and the Commission registry. The draft must be labelled as alignment with the semantic model, never as conformance, and every conformance verdict must carry rule-set identity and artefact version.", "The imported UN/CEFACT BRS Cross Industry Invoice v2.0.5 was TBG-approved in 2008; confirm it is still the current published process baseline (and check it against the CII maximum dataset and any later BRS revision) before the accepted self-billing and prepayment process finding is published as canonical.", "Multi-profile domain validation is unmet: the normative spine is EU law plus a European CIUS. Validate against at least one non-EU profile — a no-mandate voluntary market, an Asia-Pacific four-corner adoption, and one clearance regime — before any cross-jurisdiction usability claim.", "Registry metadata is unreconciled: the two providers assert different registry_ids for the same model_id, the entry still carries a legacy Document & Record alias and specification reference, and the parent identifier is empty while a validation flag suggests a parent link. Resolve registry_id, alias and parent before registry publication." ], "deferredResearch": [ "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." ] }, "statistics": { "sources": 22, "bundles": 6, "layers": 15, "findings": 28, "questions": 113, "artifacts": 30, "functions": 14 } }