# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-25T20:36:36Z", "synthesisSha256": "621ee399d96179840aa6c20df814cf38c0842a03d8420d1edabeec07c3096567", "providerMode": "dual-provider", "providers": [ "Claude", "Grok" ], "waivedProviders": [] }, "metaModel": { "id": "WM-ECO-016", "registryId": "vr.wm-eco-016", "name": "Financial Transaction / Journal Entry", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Society, people and institutions", "industry": [ "Cross-industry" ], "domain": [ "SOC.ECO.TXN" ], "tags": [ "financial", "transaction", "journal", "entry", "soc.eco.txn" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-eco-016-financial-transaction-journal-entry/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-eco-016", "model": { "registry_id": "vr.wm-eco-016", "model_id": "WM-ECO-016", "name": "Financial Transaction / Journal Entry", "entry_kind": "aggregate", "purpose": "Model the atomic accounting posting: a balanced set of debit and credit lines recording one economic event in a ledger, with the identity, time, provenance, authority, evidence and retention context an agent needs to create, validate, post, correct, audit and export it.", "scope_statement": "The subject is one journal entry (posting document) treated as an aggregate: an entry header plus two or more posting lines that must balance, together with everything required to establish that the posting is authentic, authorised, correctly timed, correctly measured, and reproducible for audit. It covers the entry as recorded in a ledger of record and as exported for audit or tax inspection. It does not cover the accounts it posts to, the payment or invoice that caused it, or the financial statements derived from it; those are neighbouring models. The model is storage-neutral: SAF-T XML, XBRL GL instances, pipe-delimited audit data files, ERP tables, MongoDB documents and append-only ledgers are projections of the same semantics.", "in_scope": [ "Entry header and posting lines, their identifiers, and the balancing invariant between debits and credits", "Monetary measurement: amount, direction, transaction currency, functional and reporting currency translation, rounding", "Distinct time roles: document date, accounting effective date, posting date, value date, system entry (ingestion) time, approval time", "Entry lifecycle from draft through posting to immutability, plus reversal, storno and correction linkage", "Provenance: source system, source document reference, derivation rule, preparer, approver, batch and interface lineage", "Authority and segregation of duties governing who may post what, where and when", "Fiscal period assignment, period state (open, soft-closed, hard-closed) and cut-off treatment", "Tax and analytical attributes carried on lines (tax code, taxable base, cost centre, project, segment, counterparty)", "Validation, reconciliation to account balances, completeness of the extracted population and control totals", "Audit risk signals on entries, supporting evidence, change-history and integrity controls", "Access control, regulator and auditor access, retention, legal hold and lawful disposal", "Export and exchange profiles (SAF-T, XBRL GL, audit data standards, statement entries) and code-list mapping" ], "out_of_scope": [ "Chart of accounts, account master data and derived account balances (owned by WM-ECO-015 Financial Account)", "Payment initiation, clearing and settlement mechanics of a payment instruction (owned by WM-ECO-009 Payment)", "Invoice and other commercial source-document content and their legal validity requirements", "Financial statements, consolidation output and disclosure taxonomies", "Legal entity, customer and supplier master records, including LEI issuance and KYC", "Currency, unit-of-measure and country code registries as registries", "Budgeting, commitment and encumbrance accounting, and management forecasts", "Tax return computation and filing obligations", "Consensus, cryptographic and network mechanics of distributed-ledger platforms" ], "boundary_notes": [ { "neighbor": "WM-ECO-015 Financial Account (parent, CONTAINS)", "distinction": "The account owns the chart-of-accounts record and derived balances; this model owns the posting event and its balancing invariant. Account existence and status are referenced preconditions, never redefined here. Audit data and SAF-T structures likewise separate the chart of accounts and trial balance from general-ledger entries.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004" ] }, { "neighbor": "WM-ECO-009 Payment (COMPOSE, produces postings)", "distinction": "A payment is an instruction and a value transfer; a journal entry is its accounting representation. One payment may produce several postings in several ledgers, and a bank statement entry is the account servicer's own posting, not the customer's journal entry. Booking status and settlement finality are read from the payment side and only referenced here.", "source_refs": [ "SRC-010", "SRC-011" ] }, { "neighbor": "Invoice and commercial source-document model", "distinction": "SAF-T and comparable audit files place source documents in a separate section from general-ledger entries. The entry carries a resolvable reference and a document archive number, but the legal content and format of the invoice belong to the source-document model.", "source_refs": [ "SRC-001", "SRC-013" ] }, { "neighbor": "Financial reporting and disclosure model", "distinction": "Aggregation into statements, and the taxonomies used to report them, sit outside. XBRL GL provides an explicit mapping module (SRCD) to financial reporting taxonomies precisely because the two layers are distinct.", "source_refs": [ "SRC-002", "SRC-008" ] }, { "neighbor": "Party / legal entity model", "distinction": "Counterparties are referenced by governed identifiers such as the ISO 17442 Legal Entity Identifier; the entry never becomes the master record for entity reference data or ownership structure.", "source_refs": [ "SRC-009" ] }, { "neighbor": "Economic event ontology (ISO/IEC 15944-4 REA)", "distinction": "REA models resources, economic events and agents at business level. This model deliberately covers only the accounting artifact derived from such events; duplicating resource and agent modelling here would collide with that ontology. The alignment is asserted at catalogue level only and is marked as an evidence gap.", "source_refs": [ "SRC-014" ] } ] }, "sources": [ { "id": "SRC-001", "title": "Guidance for the Standard Audit File - Tax, Version 2.0 (Appendix B: SAF-T Schema version 2.00)", "organization": "OECD Forum on Tax Administration", "url": "https://web-archive-storage.oecd.org/aemint-web-archive-prod/web-archive/cc/ccd3b76ffdaf3c1f3e185a390dba41be2876b0e826925278bbb3e62ad37442bf.pdf", "version_or_date": "Version 2.0", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:10:00Z", "relevance": "Defines the SAF-T file structure: header, master files, GeneralLedgerEntries (journal, transaction, line) and source documents, with control totals and tax information. Retrieved as PDF; structural detail corroborated by SRC-003 and SRC-013 because the PDF text layer was not machine-extractable." }, { "id": "SRC-002", "title": "XBRL Global Ledger Taxonomy Framework 2015", "organization": "XBRL International Inc.", "url": "https://www.xbrl.org/int/gl/2015-03-25/gl-framework-REC-2015-03-25.html", "version_or_date": "Recommendation, 2015-03-25", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:12:00Z", "relevance": "Normative representation of journal entries: accountingEntries/entryHeader/entryDetail, entriesType, entryNumber, postingDate and enteredDate, account and accountMainID, debitCreditCode, amount and signOfAmount, plus MUC (multi-currency), TAF (tax audit file) and SRCD (mapping to reporting taxonomies) modules." }, { "id": "SRC-003", "title": "Audit Data Standards: General Ledger Standard", "organization": "AICPA (American Institute of CPAs)", "url": "https://www.aicpa-cima.com/resources/download/general-ledger-standard-audit-data-standards", "version_or_date": "July 2015", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:26:00Z", "relevance": "Defines GL_Detail, Trial_Balance, Chart_of_Accounts, Source_Listing and Business_Unit_Listing tables, journal entry line fields, entered/effective/approved/last-modified date and actor fields, and supplemental questions and validation routines for completeness and integrity. Offered as pipe-delimited flat file or XBRL GL." }, { "id": "SRC-004", "title": "ISO 21378:2019 Audit data collection", "organization": "International Organization for Standardization", "url": "https://www.iso.org/standard/70823.html", "version_or_date": "First edition, 2019", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:08:00Z", "relevance": "Establishes common definitions of accounting data elements and a modular structure (Base, General Ledger, AR, Sales, AP, Purchase, Inventory, PPE) for expressing accounting information independently of the accounting or ERP system. Catalogue entry consulted; full text is paywalled, so field-level claims are not asserted from this source." }, { "id": "SRC-005", "title": "AS 2401: Consideration of Fraud in a Financial Statement Audit", "organization": "Public Company Accounting Oversight Board (PCAOB)", "url": "https://pcaobus.org/oversight/standards/auditing-standards/details/AS2401", "version_or_date": "Current standard as retrieved 2026-08-25", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:18:00Z", "relevance": "Paragraphs .58-.62 require testing of journal entries and other adjustments and list characteristics of fraudulent entries: unrelated, unusual or seldom-used accounts; unusual posters; period-end and post-closing timing; missing descriptions; round numbers; accounts with significant estimates." }, { "id": "SRC-006", "title": "17 CFR 240.17a-4 - Records to be preserved by certain exchange members, brokers and dealers", "organization": "U.S. Securities and Exchange Commission (text hosted by Cornell Legal Information Institute)", "url": "https://www.law.cornell.edu/cfr/text/17/240.17a-4", "version_or_date": "Current CFR text as retrieved 2026-08-25", "source_type": "legislation", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:22:00Z", "relevance": "Six-year retention for blotters, ledgers and journals with the first two years easily accessible; electronic recordkeeping either in non-rewriteable non-erasable (WORM) form or under a complete time-stamped audit trail preserving original and modified records with actor identity; indexing, immediate download, and third-party access undertaking or designated executive officer." }, { "id": "SRC-007", "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-25T09:20:00Z", "relevance": "Defines full-date, full-time and date-time with mandatory seconds and an explicit time-offset of Z or +/-HH:MM, the -00:00 convention for unknown local offset, and leap-second handling. Basis for the model's timestamp rule." }, { "id": "SRC-008", "title": "Conceptual Framework for Financial Reporting", "organization": "IFRS Foundation / International Accounting Standards Board", "url": "https://www.ifrs.org/issued-standards/list-of-standards/conceptual-framework/", "version_or_date": "Issued March 2018; effective for policy development from 1 January 2020", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:24:00Z", "relevance": "Supplies the definitions of assets, liabilities, equity, income and expenses, the recognition and derecognition criteria, measurement bases and unit-of-account concepts that determine whether and at what amount a posting may be made." }, { "id": "SRC-009", "title": "Introducing the Legal Entity Identifier (LEI)", "organization": "Global Legal Entity Identifier Foundation (GLEIF)", "url": "https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei", "version_or_date": "Retrieved 2026-08-25; ISO 17442 (Part 2 published 2019)", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:23:00Z", "relevance": "Governed 20-character global identifier for legal entities under ISO 17442, administered by GLEIF with ROC oversight; supports the second tier of the identity priority for reporting entity and counterparty references on postings." }, { "id": "SRC-010", "title": "ISO 20022 Message Definition Report Part 2 - Bank-to-Customer Cash Management", "organization": "ISO 20022 Registration Authority", "url": "https://www.iso20022.org/sites/default/files/documents/messages/mdr_part_2/ISO20022_MDRPart2_BankToCustomerCashManagement_2018_2019_v1_0.pdf", "version_or_date": "Maintenance 2018-2019, v1.0 (camt.052.001.08, camt.053.001.08, camt.054.001.08)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:32:00Z", "relevance": "Defines the account-servicer Entry / EntryDetails / TransactionDetails structure with EntryReference, Amount, CreditDebitIndicator (CRDT/DBIT), ReversalIndicator, Status (BOOK for booked entries), BookingDate, ValueDate, AccountServicerReference and BankTransactionCode - the interoperability anchor for transfer-derived postings." }, { "id": "SRC-011", "title": "Principles for financial market infrastructures", "organization": "Committee on Payment and Settlement Systems (BIS) and IOSCO", "url": "https://www.bis.org/cpmi/publ/d101a.htm", "version_or_date": "16 April 2012", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:30:00Z", "relevance": "Establishes settlement finality and money settlement principles governing when a transfer becomes irrevocable and unconditional, which determines whether a related posting may be treated as final rather than provisional. Landing page retrieved; principle text is in the linked PDF, so only the existence, date and subject matter are asserted." }, { "id": "SRC-012", "title": "Companies Act 2006, section 386 (duty to keep accounting records) and section 388", "organization": "United Kingdom Parliament / The National Archives (legislation.gov.uk)", "url": "https://www.legislation.gov.uk/ukpga/2006/46/section/386", "version_or_date": "Current consolidated text as retrieved 2026-08-25", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:33:00Z", "relevance": "Statutory requirement for records sufficient to show and explain transactions and disclose financial position with reasonable accuracy at any time, including entries from day to day of all sums received and expended and the matters in respect of which receipt and expenditure takes place; section 388 sets 3-year (private) and 6-year (public) retention." }, { "id": "SRC-013", "title": "Norwegian SAF-T schemas, code lists and test files", "organization": "Skatteetaten (Norwegian Tax Administration)", "url": "https://github.com/Skatteetaten/saf-t", "version_or_date": "SAF-T Financial schema versions 1.3 and 1.4, retrieved 2026-08-25", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T09:28:00Z", "relevance": "Working national profile of OECD SAF-T publishing versioned schemas, standard-account code lists and conformance test files; evidence that national profiles constrain and extend the base schema and that code lists are versioned artifacts in their own right." }, { "id": "SRC-014", "title": "ISO/IEC 15944-4:2015 Information technology - Business operational view - Part 4: Business transaction scenarios - Accounting and economic ontology", "organization": "ISO/IEC JTC 1", "url": "https://www.iso.org/standard/67199.html", "version_or_date": "Second edition, 2015", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T09:06:00Z", "relevance": "Defines the accounting and economic (REA: Resource-Event-Agent) ontology for business transaction scenarios, used here only to fix the boundary between business-level economic events and the accounting artifact. Catalogue entry consulted; full text paywalled, so no field-level claims are drawn from it." }, { "id": "SRC-015", "title": "XBRL Global Ledger: Transactional Reporting", "organization": "XBRL International", "url": "https://www.xbrl.org/the-standard/what/global-ledger/", "version_or_date": "accessed 2026-08-25", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T16:30:00Z", "relevance": "Defines XBRL GL as the system-independent record of original ledger detail, journal entries and drill-down from summary reports, including audit, consolidation and transfer use." }, { "id": "SRC-016", "title": "Audit Focus: Journal Entries", "organization": "Public Company Accounting Oversight Board", "url": "https://pcaobus.org/resources/staff-publications/audit-focus/audit-focus-journal-entries", "version_or_date": "January 2025", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T16:30:00Z", "relevance": "Authoritative staff reminder of journal-entry testing: controls over initiate-authorize-record-process, completeness of the population, manual versus automated origin, post-closing and fraudulent-entry characteristics." }, { "id": "SRC-017", "title": "AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements", "organization": "Public Company Accounting Oversight Board", "url": "https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201", "version_or_date": "current PCAOB auditing standard as published 2026-08-25", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T16:30:00Z", "relevance": "Requires controls over journal entries and period-end adjustments, significant unusual transactions that result in late or unusual journal entries, and procedures to initiate, authorize, record and process entries in the general ledger." }, { "id": "SRC-018", "title": "Catalogue of messages", "organization": "ISO 20022 Registration Authority", "url": "https://www.iso20022.org/catalogue-messages", "version_or_date": "current catalogue as accessed 2026-08-25", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T16:30:00Z", "relevance": "Official inventory of approved ISO 20022 message definitions, including cash-management and account-reporting messages used to report booked cash transactions." }, { "id": "SRC-019", "title": "ISO 20022 Bank Transaction Codes - External Code Sets", "organization": "ISO 20022 Registration Authority", "url": "https://www.iso20022.org/sites/default/files/2020-08/BTC_ExternalCodeListDescription_31Aug2020.doc", "version_or_date": "31 August 2020", "source_type": "classifier", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T16:30:00Z", "relevance": "Harmonised bank transaction codes for bank-to-customer cash account reporting so the account owner can reconcile cash movements to sub-ledgers and processing systems." }, { "id": "SRC-020", "title": "ISO 4217 — Currency codes", "organization": "International Organization for Standardization", "url": "https://www.iso.org/iso-4217-currency-codes.html", "version_or_date": "ISO 4217:2015", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T16:30:00Z", "relevance": "Alphabetic and numeric currency codes and minor-unit exponents required to express posting amounts without ambiguity." }, { "id": "SRC-021", "title": "Financial Industry Business Ontology (FIBO) repository", "organization": "EDM Council / Object Management Group", "url": "https://github.com/edmcouncil/fibo", "version_or_date": "continuous community publication; accessed 2026-08-25", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T16:30:00Z", "relevance": "Formal OWL vocabulary for financial contracts and process flows; BP domain transaction semantics are an adjacent meaning of financial transaction that must not be collapsed into a ledger posting." }, { "id": "SRC-022", "title": "ISO 20022 Message Definitions", "organization": "ISO 20022 Registration Authority", "url": "https://www.iso20022.org/iso-20022-message-definitions", "version_or_date": "current catalogue listing as accessed 2026-08-25", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T16:30:00Z", "relevance": "Machine-readable message inventory and schemas for ISO 20022, including account management and other financial-message families that carry booked amounts and references." }, { "id": "SRC-023", "title": "Transactional Reporting (Global Ledger)", "organization": "XBRL International", "url": "https://specifications.xbrl.org/transactional.html", "version_or_date": "accessed 2026-08-25", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T16:30:00Z", "relevance": "States that XBRL GL represents chart of accounts, journal entries and historical transactions without requiring a standardised chart of accounts." }, { "id": "SRC-024", "title": "ISO 20022 MDR Part 1 BankToCustomer Cash Management", "organization": "ISO 20022 Registration Authority", "url": "https://www.iso20022.org/sites/default/files/2020-12/ISO20022_MDRPart1_BankToCustomerCashManagement_2020_2021_v1_ForSEGReview.docx", "version_or_date": "2020-2021 v1 For SEG Review, dated 2020-12", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T16:30:00Z", "relevance": "Message definition report for bank-to-customer cash management, including BankToCustomerStatement camt.053, designed to report cash transactions between an account servicer and its customers." } ], "structure": { "bundles": [ { "id": "bdl-identity-classification", "name": "Identity and classification of the posting", "description": "What this entry is, how it is named, which book it lives in and how it is typed.", "rationale": "Every downstream operation - validation, correction, export, audit selection - depends on being able to name the entry unambiguously and know which ledger and category it belongs to. Audit and tax file formats all begin with an entry identifier plus journal and ledger context.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "layers": [ { "id": "lyr-entry-identity", "name": "Entry and line identification", "description": "Identifiers for the entry aggregate and its lines, their scope, and the external references that must resolve.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "findings": [ { "id": "fnd-entry-identifier", "name": "Entry and posting line identification", "description": "How the entry and each of its lines are named by the ledger of record, and which external references must resolve back to them.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-009", "SRC-010" ], "questions": [ { "id": "q-entry-master-id", "text": "Which system of record issues this entry's authoritative identifier, and under what scheme?", "kind": "identity", "answer_data": [ "entry identifier value", "issuing system identifier", "identifier scheme name and version" ] }, { "id": "q-line-address", "text": "How is each posting line addressed, and does that address stay stable across export and re-import?", "kind": "identity", "answer_data": [ "line identifier or line number", "addressing rule", "stability guarantee statement" ] }, { "id": "q-entry-cross-reference", "text": "Which external references - payment end-to-end reference, bank entry reference, source document number - must resolve back to this entry?", "kind": "relationship", "answer_data": [ "reference type", "reference value", "target model or system", "resolution method" ] }, { "id": "q-id-uniqueness-scope", "text": "Over what scope and for how long is the entry identifier guaranteed unique and never reused?", "kind": "constraint", "answer_data": [ "uniqueness scope (ledger, entity, fiscal year, file)", "reuse prohibition statement", "collision handling rule" ] } ], "data_elements": [ { "id": "de-entry-id", "name": "Entry identifier", "description": "Authoritative identifier of the entry issued by the ledger of record.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-line-id", "name": "Posting line identifier", "description": "Identifier or ordinal of a line within the entry; unique within the entry.", "value_kind": "identifier", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "de-external-ref", "name": "External reference", "description": "Typed reference to a payment, statement entry or source document held in another model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-010" ] } ], "artifacts": [ { "id": "art-posted-entry-record", "name": "Posted journal entry record", "description": "The immutable record of the entry header and its balanced lines as held by the ledger of record.", "media_or_form": [ "structured ledger record", "audit-file transaction node", "XBRL GL entryHeader with entryDetail children" ], "serial": false, "identity_strategy": "Authoritative entry identifier issued by the ledger of record, qualified by ledger and reporting entity; line identity is entry identifier plus line number.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "fnd-entry-classification", "name": "Journal assignment and entry typing", "description": "Which journal or daybook the entry belongs to and how its nature and origin are coded.", "source_refs": [ "SRC-001", "SRC-002", "SRC-005", "SRC-010" ], "questions": [ { "id": "q-journal-assignment", "text": "To which journal, daybook or subledger is the entry assigned, and who governs that code list?", "kind": "classification", "answer_data": [ "journal identifier", "journal description", "code list owner and version" ] }, { "id": "q-manual-vs-automated", "text": "Was the entry keyed manually, generated by an automated interface, or produced from a recurring template?", "kind": "provenance", "answer_data": [ "origin category", "template or interface identifier", "manual indicator" ] }, { "id": "q-transaction-type-code", "text": "Which transaction type or bank transaction code describes the economic nature of the posting?", "kind": "classification", "answer_data": [ "transaction type code", "code scheme", "bank transaction code (domain, family, sub-family)" ] }, { "id": "q-classification-change", "text": "May an entry's classification change after posting, and how would such a change be recorded?", "kind": "lifecycle", "answer_data": [ "mutability rule for classification", "permitted reclassification mechanism", "change record reference" ] } ], "data_elements": [ { "id": "de-journal-id", "name": "Journal identifier", "description": "Code of the journal, daybook or subledger holding the entry.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-entry-origin", "name": "Entry origin category", "description": "Whether the entry is manual, interfaced, recurring, adjusting, closing, reversing or consolidating.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-005" ] }, { "id": "de-bank-txn-code", "name": "Bank transaction code", "description": "Account-servicer classification of a transfer-derived entry (domain, family, sub-family).", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "art-entry-type-code-list", "name": "Entry type and journal code list", "description": "Versioned list of journal codes, entry origin categories and transaction type codes in force for a ledger.", "media_or_form": [ "code list document", "machine-readable code table" ], "serial": false, "identity_strategy": "Code list namespace plus issuing authority plus version; individual codes identified by scheme-qualified code value.", "source_refs": [ "SRC-002", "SRC-013" ] } ], "inline_only_rationale": null } ] }, { "id": "lyr-ledger-context", "name": "Ledger and framework context", "description": "The book, reporting entity, accounting framework and functional currency that give the posting meaning.", "source_refs": [ "SRC-001", "SRC-002", "SRC-008", "SRC-009" ], "findings": [ { "id": "fnd-ledger-book-context", "name": "Ledger, entity and accounting framework context", "description": "Which book the entry lives in, which legal entity owns it, and under which framework and functional currency it is measured.", "source_refs": [ "SRC-001", "SRC-002", "SRC-008", "SRC-009", "SRC-012" ], "questions": [ { "id": "q-ledger-identity", "text": "In which ledger or book - statutory, tax, management or parallel framework ledger - is this entry recorded?", "kind": "classification", "answer_data": [ "ledger identifier", "ledger purpose category", "parallel ledger set membership" ] }, { "id": "q-reporting-entity", "text": "Which legal entity and business unit own the ledger, and by which governed identifier are they named?", "kind": "ownership", "answer_data": [ "legal entity identifier (LEI where available)", "business unit code", "tax registration identifier" ] }, { "id": "q-framework-jurisdiction", "text": "Which accounting framework and jurisdiction govern the ledger, and what is its functional currency?", "kind": "authority", "answer_data": [ "framework name and version", "jurisdiction code", "functional currency code" ] }, { "id": "q-parallel-ledgers", "text": "When one economic event is posted to several parallel ledgers, how are those postings linked to each other?", "kind": "relationship", "answer_data": [ "sibling posting identifiers", "linkage mechanism", "divergence reason where amounts differ" ] } ], "data_elements": [ { "id": "de-ledger-id", "name": "Ledger identifier", "description": "Identifier of the book of account in which the entry is recorded.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-reporting-entity-ref", "name": "Reporting entity reference", "description": "Governed identifier of the legal entity owning the ledger.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-001" ] }, { "id": "de-functional-currency", "name": "Functional currency", "description": "Currency in which the ledger measures results.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "art-ledger-profile", "name": "Ledger definition profile", "description": "Declaration of a ledger's purpose, owning entity, framework, functional currency, fiscal calendar and code lists.", "media_or_form": [ "configuration document", "registry record" ], "serial": false, "identity_strategy": "Ledger identifier qualified by reporting entity identifier; version-stamped on each change of framework or currency.", "source_refs": [ "SRC-001", "SRC-008", "SRC-012" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "bdl-composition-balancing", "name": "Composition, balancing and measurement", "description": "How the entry is built from lines, why it must balance, and how each line's amount is measured.", "rationale": "The balancing invariant and the monetary measurement of each line are the defining properties that separate a journal entry from any other record of an event; audit files carry explicit debit and credit amounts and control totals precisely to make the invariant checkable.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-008" ], "layers": [ { "id": "lyr-posting-structure", "name": "Posting structure", "description": "Header-to-line composition, the balancing invariant and the analytical dimensions carried by lines.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "findings": [ { "id": "fnd-entry-line-composition", "name": "Header-to-line composition", "description": "What constitutes a complete entry, which attributes sit on the header and which repeat on each line.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "questions": [ { "id": "q-min-lines", "text": "What is the minimum and maximum set of posting lines that constitutes a complete entry?", "kind": "composition", "answer_data": [ "minimum line count", "maximum line count or unbounded flag", "completeness rule" ] }, { "id": "q-line-account-ref", "text": "Which account does each line debit or credit, and how is that account reference resolved and validated?", "kind": "relationship", "answer_data": [ "account identifier per line", "chart of accounts reference", "resolution and activity check" ] }, { "id": "q-header-line-attributes", "text": "Which attributes belong on the entry header and which must be repeated on every line?", "kind": "composition", "answer_data": [ "header attribute list", "line attribute list", "attributes permitted at both levels with precedence rule" ] } ], "data_elements": [ { "id": "de-posting-line", "name": "Posting line", "description": "One debit or credit against a single account, with amount, direction and qualifying attributes.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "de-account-ref", "name": "Account reference", "description": "Reference from a line to the account it posts against, resolved in the account model.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-entry-description", "name": "Entry description", "description": "Narrative explaining the entry; a separate line-level narrative may also exist.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Composition is a structural property of the entry record already captured by art-posted-entry-record; it produces no separate artifact of its own. Header and line attributes are inline data within that record, and the account it points to is an artifact owned by WM-ECO-015." }, { "id": "fnd-balancing-invariant", "name": "Balancing invariant and control totals", "description": "At which level debits must equal credits, which control totals travel with a batch, and what happens on imbalance.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "questions": [ { "id": "q-balance-rule", "text": "At which level - line set, entry, batch, ledger or currency - must debits equal credits, and to what tolerance?", "kind": "constraint", "answer_data": [ "balancing scope", "tolerance value and currency", "per-currency balancing flag" ] }, { "id": "q-control-totals", "text": "Which control totals accompany a batch or export, and how are they recomputed on receipt?", "kind": "validation", "answer_data": [ "entry count", "total debit", "total credit", "recomputation procedure" ] }, { "id": "q-imbalance-handling", "text": "What happens to an entry that fails the balancing test at capture, at posting and after export?", "kind": "exception", "answer_data": [ "rejection or quarantine rule per stage", "suspense account policy", "escalation path" ] } ], "data_elements": [ { "id": "de-total-debit", "name": "Total debit", "description": "Sum of debit amounts asserted for an entry, batch or export.", "value_kind": "quantity", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-total-credit", "name": "Total credit", "description": "Sum of credit amounts asserted for an entry, batch or export.", "value_kind": "quantity", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-entry-count", "name": "Number of entries", "description": "Count of entries asserted in a batch or export header.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "art-batch-control-totals", "name": "Batch control total record", "description": "Header assertion of entry count, total debit and total credit for a batch or exported period.", "media_or_form": [ "export file header", "batch manifest" ], "serial": true, "identity_strategy": "Batch or export identifier issued by the producing system, plus the ledger identifier and asserted period; never identified by the file's date alone.", "source_refs": [ "SRC-001", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "fnd-analytical-dimensions", "name": "Analytical dimensions on postings", "description": "The non-account qualifiers a line may carry and the rules that make them mandatory.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "questions": [ { "id": "q-dimension-set", "text": "Which analytical dimensions - cost centre, project, segment, counterparty, product - may qualify a posting line?", "kind": "classification", "answer_data": [ "dimension name", "permitted value set reference", "dimension owner" ] }, { "id": "q-dimension-required", "text": "Which dimension values are mandatory for which account ranges, and who sets that rule?", "kind": "requirement", "answer_data": [ "account range", "required dimension list", "rule owner and effective period" ] }, { "id": "q-quantity-alongside-amount", "text": "When a line carries a non-monetary quantity or unit, how is it recorded alongside the monetary amount?", "kind": "measurement", "answer_data": [ "quantity value", "unit of measure code", "relationship to monetary amount" ] } ], "data_elements": [ { "id": "de-dimension-value", "name": "Analytical dimension value", "description": "Typed qualifier on a line, such as cost centre, project, segment or counterparty.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "de-line-quantity", "name": "Line quantity", "description": "Non-monetary quantity and unit associated with a posting line.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-counterparty-ref", "name": "Counterparty reference", "description": "Customer, supplier or other counterparty associated with the line.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Dimension values are inline coded attributes on the posting line; the authoritative value sets are code-list artifacts already governed by art-entry-type-code-list and by the dimension owner's own model, so no additional artifact is created here." } ] }, { "id": "lyr-monetary-measurement", "name": "Monetary measurement", "description": "Amount, direction, currency, translation to reporting currencies and tax attributes.", "source_refs": [ "SRC-002", "SRC-008", "SRC-010" ], "findings": [ { "id": "fnd-amount-and-direction", "name": "Amount, direction and currency of a posting", "description": "How a line's value and its debit or credit sense are represented, with scale, rounding and edge cases.", "source_refs": [ "SRC-002", "SRC-003", "SRC-010" ], "questions": [ { "id": "q-direction-representation", "text": "Is direction represented by an explicit debit or credit indicator, by a signed amount, or by both, and which representation is authoritative?", "kind": "measurement", "answer_data": [ "direction indicator value", "signed amount convention", "authoritative representation declaration" ] }, { "id": "q-currency-of-amount", "text": "In which currency is the line amount denominated, and how is that currency code governed?", "kind": "measurement", "answer_data": [ "currency code", "code list and version", "minor unit / scale" ] }, { "id": "q-precision-rounding", "text": "What scale and rounding rule apply to the amount, and where is any rounding difference posted?", "kind": "constraint", "answer_data": [ "decimal scale", "rounding method", "rounding difference account" ] }, { "id": "q-zero-negative", "text": "Are zero-value and negative-value postings permitted, and what do they mean here?", "kind": "exception", "answer_data": [ "zero-amount policy", "negative amount policy and meaning", "distinction from a reversing posting" ] } ], "data_elements": [ { "id": "de-line-amount", "name": "Line amount", "description": "Non-negative magnitude of the posting in the transaction currency, stored as an exact decimal.", "value_kind": "quantity", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "de-credit-debit-indicator", "name": "Credit/debit indicator", "description": "Explicit direction of the posting, corresponding to debitCreditCode or CRDT/DBIT.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-010" ] }, { "id": "de-transaction-currency", "name": "Transaction currency", "description": "Currency in which the line amount is denominated.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Amount, direction and currency are atomic inline values on the posting line inside art-posted-entry-record; separating them into an artifact would fragment the record that must be verified as a whole." }, { "id": "fnd-currency-translation", "name": "Multi-currency translation and rate provenance", "description": "Additional currency amounts stored on a line, the rate used, and how later revaluations link back.", "source_refs": [ "SRC-002", "SRC-003", "SRC-008" ], "questions": [ { "id": "q-reporting-amounts", "text": "Which additional currency amounts - functional, group reporting or tax - are stored on the line?", "kind": "measurement", "answer_data": [ "currency role", "amount per role", "storage-versus-derivation flag" ] }, { "id": "q-rate-provenance", "text": "Which exchange rate, rate date and rate source were applied, and who published that rate?", "kind": "provenance", "answer_data": [ "rate value", "rate date", "rate type", "publishing source identifier" ] }, { "id": "q-revaluation-entries", "text": "How are later revaluation or translation adjustments linked back to the original posting?", "kind": "relationship", "answer_data": [ "original entry reference", "adjustment entry reference", "link type and reason" ] } ], "data_elements": [ { "id": "de-reporting-amount", "name": "Reporting currency amount", "description": "Translated amount in the functional or group reporting currency, with its currency role.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "de-fx-rate", "name": "Exchange rate applied", "description": "Rate value, rate type and rate date used to translate the line amount.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-fx-rate-source", "name": "Exchange rate source", "description": "Publisher of the applied rate, such as a central bank or contractual rate provider.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "art-fx-rate-table", "name": "Applied exchange rate table", "description": "Versioned set of rates, rate types and effective dates used for translating postings.", "media_or_form": [ "rate table", "reference data feed snapshot" ], "serial": true, "identity_strategy": "Rate source identifier plus rate type plus effective date range plus publication sequence; the effective date is an attribute of the rate, not the identifier of the table.", "source_refs": [ "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "fnd-tax-attributes", "name": "Tax attributes carried by postings", "description": "Tax codes, taxable base, tax amounts and tax point dates carried at line level for audit and tax reporting.", "source_refs": [ "SRC-001", "SRC-002", "SRC-013" ], "questions": [ { "id": "q-tax-code-line", "text": "Which tax code, tax type and tax jurisdiction apply to the line, and against which taxable base?", "kind": "classification", "answer_data": [ "tax code", "tax type", "jurisdiction code", "taxable base amount" ] }, { "id": "q-tax-amount-split", "text": "How are taxable base, tax amount and any non-deductible portion recorded as separate values?", "kind": "measurement", "answer_data": [ "tax base amount", "tax amount", "non-deductible amount", "tax percentage" ] }, { "id": "q-tax-point-date", "text": "Which date determines the tax point, and how does it differ from the posting date?", "kind": "temporal", "answer_data": [ "tax point date", "posting date", "rule linking the two" ] } ], "data_elements": [ { "id": "de-tax-code", "name": "Tax code", "description": "Jurisdiction-specific tax classification applied to the line.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-013" ] }, { "id": "de-tax-amount", "name": "Tax amount", "description": "Tax value attributable to the line, alongside its taxable base.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] } ], "artifacts": [ { "id": "art-tax-code-map", "name": "Tax code table and mapping", "description": "Versioned table of tax codes, rates, jurisdictions and their mapping to statutory reporting categories.", "media_or_form": [ "code table", "mapping specification" ], "serial": false, "identity_strategy": "Jurisdiction plus issuing authority plus code list version; each code identified by scheme-qualified code value with validity period as an attribute.", "source_refs": [ "SRC-001", "SRC-013" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "bdl-time-lifecycle", "name": "Time, period and lifecycle", "description": "Distinct time roles, fiscal period placement, state transitions, correction and settlement finality.", "rationale": "Journal entries carry several genuinely different dates, and the audit consequences of confusing them are severe: period assignment drives reporting, capture time drives audit trail, value date drives cash availability, and finality determines whether a posting is provisional.", "source_refs": [ "SRC-002", "SRC-003", "SRC-005", "SRC-007", "SRC-010" ], "layers": [ { "id": "lyr-time-semantics", "name": "Time semantics", "description": "The separate date and timestamp roles on an entry and the fiscal period they resolve to.", "source_refs": [ "SRC-002", "SRC-003", "SRC-007" ], "findings": [ { "id": "fnd-entry-date-semantics", "name": "Distinct date and timestamp roles", "description": "Which dates and instants an entry carries, how event time is separated from capture time, and how each is formatted.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-007", "SRC-010" ], "questions": [ { "id": "q-date-roles", "text": "Which distinct date and timestamp roles does this entry carry, and what does each one mean?", "kind": "temporal", "answer_data": [ "document date", "accounting effective date", "posting date", "value date", "approval timestamp" ] }, { "id": "q-event-vs-capture", "text": "How is the accounting event time separated from the system capture or ingestion time on this record?", "kind": "provenance", "answer_data": [ "event time value and role", "system entry timestamp", "capturing system identifier" ] }, { "id": "q-timestamp-format", "text": "In what format and offset are instants stored, and how are pure accounting dates distinguished from instants?", "kind": "interoperability", "answer_data": [ "timestamp format declaration", "offset handling rule", "date-versus-instant type flag" ] }, { "id": "q-backdating", "text": "Under whose authority may an entry be dated earlier than its capture time, and how is that flagged?", "kind": "authority", "answer_data": [ "backdating permission holder", "backdating reason code", "flag on the record" ] } ], "data_elements": [ { "id": "de-effective-date", "name": "Accounting effective date", "description": "Calendar date determining the accounting period of the entry.", "value_kind": "date", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "de-posting-date", "name": "Posting date", "description": "Date on which the entry was posted to the ledger, distinct from its effective date.", "value_kind": "date", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-system-entry-time", "name": "System entry timestamp", "description": "Instant at which the record was captured by the system, recorded separately from event time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] }, { "id": "de-value-date", "name": "Value date", "description": "Date on which value becomes available or ceases to be available for a transfer-derived posting.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Date and timestamp roles are inline scalar attributes of the entry record and its lines. They are governed by the service-layer timestamp rule rather than by a separate artifact; creating one would detach time semantics from the record whose integrity they qualify." }, { "id": "fnd-period-and-cutoff", "name": "Fiscal period, period state and cut-off", "description": "How the entry resolves to a fiscal period, whether that period accepts postings, and how cut-off adjustments are marked.", "source_refs": [ "SRC-001", "SRC-003", "SRC-005", "SRC-012" ], "questions": [ { "id": "q-period-assignment", "text": "To which fiscal year and accounting period is the entry assigned, and by which rule?", "kind": "temporal", "answer_data": [ "fiscal year", "period number or label", "assignment rule and fiscal calendar reference" ] }, { "id": "q-period-state", "text": "Is the target period open, soft-closed or hard-closed, and who may post into each state?", "kind": "state", "answer_data": [ "period state", "permitted roles per state", "state change record" ] }, { "id": "q-cutoff-adjustment", "text": "How are cut-off, accrual and post-closing adjustments identified and separated from routine entries?", "kind": "classification", "answer_data": [ "adjustment category code", "post-closing indicator", "reversal schedule where applicable" ] } ], "data_elements": [ { "id": "de-fiscal-period", "name": "Fiscal period", "description": "Fiscal year and period to which the entry is assigned.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-period-state", "name": "Period state", "description": "Whether the period is open, soft-closed or hard-closed for posting.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "art-period-close-record", "name": "Period close record", "description": "Record that a fiscal period has been closed, by whom, with which balances and which residual open items.", "media_or_form": [ "close checklist record", "ledger control record" ], "serial": true, "identity_strategy": "Ledger identifier plus fiscal year and period label plus close sequence number issued by the ledger of record.", "source_refs": [ "SRC-003", "SRC-005", "SRC-012" ] } ], "inline_only_rationale": null } ] }, { "id": "lyr-lifecycle-state", "name": "Lifecycle, correction and finality", "description": "State model up to immutability, correction mechanics, and the finality of transfer-derived postings.", "source_refs": [ "SRC-002", "SRC-006", "SRC-010", "SRC-011" ], "findings": [ { "id": "fnd-entry-lifecycle-states", "name": "Entry states and the immutability point", "description": "Permitted states and transitions, where the record becomes immutable, and how provisional postings are marked.", "source_refs": [ "SRC-002", "SRC-006", "SRC-010" ], "questions": [ { "id": "q-state-model", "text": "What are the permitted states of an entry and the legal transitions between them?", "kind": "lifecycle", "answer_data": [ "state list", "allowed transitions", "transition trigger per edge" ] }, { "id": "q-immutability-point", "text": "At which state does the entry become immutable, and exactly which fields may no longer change?", "kind": "constraint", "answer_data": [ "immutability trigger state", "frozen field list", "fields still mutable with audit trail" ] }, { "id": "q-pending-vs-booked", "text": "How is a pending or provisional posting distinguished from a booked one by downstream consumers?", "kind": "state", "answer_data": [ "booking status code", "consumer treatment rule", "expected resolution window" ] }, { "id": "q-abandoned-drafts", "text": "What becomes of drafts that are never posted, and for how long are they kept?", "kind": "retention", "answer_data": [ "draft disposal rule", "draft retention period", "audit visibility of abandoned drafts" ] } ], "data_elements": [ { "id": "de-entry-state", "name": "Entry state", "description": "Current lifecycle state of the entry, such as draft, approved, posted or reversed.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-006" ] }, { "id": "de-booking-status", "name": "Booking status", "description": "Whether the posting is booked or still pending, for transfer-derived entries.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "State is an attribute of the entry record, and every transition is captured by art-change-audit-log. A separate lifecycle artifact would duplicate the audit trail that regulation already requires to be the authoritative history." }, { "id": "fnd-reversal-correction", "name": "Reversal, storno and correction linkage", "description": "How a posted entry is corrected without being altered, and how the corrective chain is made traceable.", "source_refs": [ "SRC-002", "SRC-005", "SRC-006", "SRC-010" ], "questions": [ { "id": "q-reversal-method", "text": "Is correction made by reversing entry, storno, or negative posting, and which method is authoritative in this ledger?", "kind": "process", "answer_data": [ "correction method", "method selection rule", "effect on account turnover figures" ] }, { "id": "q-reversal-linkage", "text": "How are the original entry, the reversing entry and any replacement entry linked in both directions?", "kind": "relationship", "answer_data": [ "original entry reference", "reversal entry reference", "replacement entry reference", "link type" ] }, { "id": "q-reversal-period", "text": "Into which period is a reversal posted when the original period is already closed?", "kind": "temporal", "answer_data": [ "reversal period assignment rule", "prior-period adjustment treatment", "disclosure trigger" ] }, { "id": "q-reversal-authority", "text": "Who may authorise a reversal, and what reason code and evidence must accompany it?", "kind": "authority", "answer_data": [ "authoriser role and identity", "reason code", "supporting evidence reference" ] } ], "data_elements": [ { "id": "de-reversal-indicator", "name": "Reversal indicator", "description": "Flag marking the entry or line as a reversal of a previous posting.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "de-corrects-entry-ref", "name": "Corrected entry reference", "description": "Reference from a corrective entry to the entry it reverses or replaces.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-006" ] }, { "id": "de-correction-reason", "name": "Correction reason code", "description": "Coded justification for the reversal or correction.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "A reversal is itself an instance of art-posted-entry-record; the corrective relationship is inline reference data linking two entry records. Introducing a distinct correction artifact would create a second, competing record of a fact the ledger must already hold." }, { "id": "fnd-settlement-finality", "name": "Booking status and settlement finality for transfers", "description": "Whether the underlying transfer is final, when it became irrevocable, and how provisional postings are unwound.", "source_refs": [ "SRC-010", "SRC-011" ], "questions": [ { "id": "q-booking-status", "text": "What booking status does the underlying transfer carry, and does this posting depend on that status?", "kind": "state", "answer_data": [ "transfer status code", "dependency declaration", "status source system" ] }, { "id": "q-finality-moment", "text": "At which moment does the transfer become irrevocable and unconditional, and how is that moment evidenced?", "kind": "event", "answer_data": [ "finality timestamp", "finality rule or system rulebook reference", "evidencing message or advice" ] }, { "id": "q-provisional-reversal", "text": "How are provisional postings unwound when a transfer is returned, recalled or rejected?", "kind": "exception", "answer_data": [ "return or recall event reference", "unwinding posting reference", "customer notification requirement" ] } ], "data_elements": [ { "id": "de-finality-time", "name": "Settlement finality timestamp", "description": "Instant at which the underlying transfer became irrevocable and unconditional.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] }, { "id": "de-settlement-system-ref", "name": "Settlement system reference", "description": "Reference to the payment or securities settlement system whose rules define finality.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [ { "id": "art-account-statement-entry", "name": "Account statement entry", "description": "Account servicer's booked entry advice used as external evidence for a transfer-derived posting.", "media_or_form": [ "bank-to-customer statement entry", "debit/credit notification", "settlement advice" ], "serial": true, "identity_strategy": "Account servicer reference or entry reference issued by the account servicer, qualified by the servicing institution identifier and statement sequence number.", "source_refs": [ "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "fnd-top-side-adjustments", "name": "Reversals, corrections and period-end adjustments", "description": "Rare but required cases include auto-reversing accruals, prior-period corrections, consolidating and reclassification adjustments, late or unusual entries, and top-side adjustments that may not appear as formal journal entries in the general ledger.", "source_refs": [ "SRC-016", "SRC-005", "SRC-017" ], "questions": [ { "id": "fnd-top-side-adjustments-q01", "text": "Is this entry a reversal, a correcting entry, a prior-period restatement, or an auto-reversing accrual, and which original entry does it supersede?", "kind": "lifecycle", "answer_data": [ "adjustment-class", "original-entry-id", "auto-reverse-date", "restatement-flag" ] }, { "id": "fnd-top-side-adjustments-q02", "text": "Is this adjustment a consolidating, combination, reclassification or other top-side item that is not reflected as a formal journal entry in the general ledger?", "kind": "exception", "answer_data": [ "is-top-side", "adjustment-channel", "in-formal-gl", "report-pack-id" ] }, { "id": "fnd-top-side-adjustments-q03", "text": "Was the entry recorded at period end or post-close, to seldom-used accounts, by an unusual preparer, or with round-number or unexplained characteristics?", "kind": "event", "answer_data": [ "is-period-end", "is-post-close", "seldom-used-accounts", "unusual-preparer", "round-number-flag", "explanation-present" ] } ], "data_elements": [ { "id": "fnd-top-side-adjustments-data01", "name": "Adjustment class", "description": "Reversal, correction, auto-reversing accrual, restatement, consolidation, reclassification or top-side.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-017" ] }, { "id": "fnd-top-side-adjustments-data02", "name": "Original entry identifier", "description": "Reference to the entry being reversed or corrected.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "fnd-top-side-adjustments-data03", "name": "Top-side flag", "description": "Whether the adjustment is outside formal general-ledger journal entries.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "fnd-top-side-adjustments-data04", "name": "Post-close flag", "description": "Whether the entry was recorded after books were closed.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-017" ] } ], "artifacts": [ { "id": "fnd-top-side-adjustments-artifact01", "name": "Reversal or adjusting voucher", "description": "Document that reverses or adjusts a prior posted entry, including link to the original.", "media_or_form": [ "reversing journal", "consolidating worksheet", "top-side pack" ], "serial": true, "identity_strategy": "New journal number for the reversing or adjusting document; original number stored as a reference, never reused as the identity of the reversal.", "source_refs": [ "SRC-016", "SRC-005" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "bdl-provenance-authority", "name": "Provenance, authority and control", "description": "Where the entry came from, who made and approved it, what may not be changed, and who was entitled to act.", "rationale": "Recordkeeping regulation and auditing standards both treat the answer to 'who did this, from what source, and could it have been altered' as the core control question for postings; the audit trail is itself a regulated object.", "source_refs": [ "SRC-005", "SRC-006", "SRC-008", "SRC-012" ], "layers": [ { "id": "lyr-provenance-audit-trail", "name": "Provenance and audit trail", "description": "Source derivation, actor attribution and the protected change history of the record.", "source_refs": [ "SRC-002", "SRC-003", "SRC-006" ], "findings": [ { "id": "fnd-source-derivation", "name": "Source system, source event and derivation rule", "description": "Which system and business event produced the entry, under which posting rule, and whether it can be re-derived.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-013" ], "questions": [ { "id": "q-source-system", "text": "Which source system, interface and batch produced this entry?", "kind": "provenance", "answer_data": [ "source system identifier", "interface or feed identifier", "batch identifier" ] }, { "id": "q-source-document", "text": "Which source document or business event does the entry represent, and how is that reference resolved?", "kind": "relationship", "answer_data": [ "source document type", "source document identifier", "document archive reference" ] }, { "id": "q-derivation-rule", "text": "Which posting rule, template or algorithm derived the lines from the source event, and in which version?", "kind": "process", "answer_data": [ "posting rule identifier", "rule version", "parameter values applied" ] }, { "id": "q-replay-determinism", "text": "Can the entry be re-derived deterministically from its source, and would re-derivation mint a new identifier?", "kind": "quality", "answer_data": [ "determinism assertion", "known non-deterministic inputs", "identifier behaviour on replay" ] } ], "data_elements": [ { "id": "de-source-system-id", "name": "Source system identifier", "description": "System that originated the entry, as recorded on the entry header.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-source-document-ref", "name": "Source document reference", "description": "Reference to the invoice, payment or other source document evidencing the entry.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-posting-rule-ref", "name": "Posting rule reference", "description": "Identifier and version of the rule or template that derived the lines.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "The source document is an artifact owned by the invoice or payment model; duplicating it here would create a second custodial copy with divergent retention. This finding contributes only the resolvable reference and the derivation metadata, which are inline attributes of the entry record." }, { "id": "fnd-actor-attribution", "name": "Actor attribution and approval", "description": "Who prepared, approved and released the entry, and how non-human actors are tied to accountable owners.", "source_refs": [ "SRC-003", "SRC-005", "SRC-006" ], "questions": [ { "id": "q-preparer-identity", "text": "Who entered the entry, under which account, and on whose behalf?", "kind": "provenance", "answer_data": [ "preparer identifier", "authentication method", "delegation or on-behalf-of reference" ] }, { "id": "q-approver-record", "text": "Who approved or released the entry, when, and under which approval rule?", "kind": "authority", "answer_data": [ "approver identifier", "approval timestamp", "approval rule reference" ] }, { "id": "q-service-account", "text": "How are entries created by service accounts, robots or scheduled jobs attributed to an accountable human owner?", "kind": "ownership", "answer_data": [ "service account identifier", "accountable owner identifier", "attribution policy reference" ] } ], "data_elements": [ { "id": "de-entered-by", "name": "Entered by", "description": "Identity of the actor who created the entry.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-006" ] }, { "id": "de-approved-by", "name": "Approved by", "description": "Identity of the actor who approved or released the entry, with approval time.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "art-approval-record", "name": "Approval and release record", "description": "Evidence of who approved an entry, when, under which rule and against which limits.", "media_or_form": [ "workflow approval record", "signed release token" ], "serial": false, "identity_strategy": "Entry identifier plus approval step identifier plus approver identity; approval instant is an attribute, never the identifier.", "source_refs": [ "SRC-003", "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "fnd-change-history-immutability", "name": "Change history, immutability and integrity", "description": "What the audit trail must capture, how originals are preserved, and how integrity of a posted entry is proven.", "source_refs": [ "SRC-005", "SRC-006", "SRC-012" ], "questions": [ { "id": "q-change-log-content", "text": "What does the change record capture for every modification or deletion attempt on a posted record?", "kind": "evidence", "answer_data": [ "action type", "actor identity", "action timestamp", "before and after values" ] }, { "id": "q-original-preservation", "text": "How are both the original and the modified version of a record preserved and retrievable?", "kind": "retention", "answer_data": [ "original version location", "version linkage", "retrieval procedure" ] }, { "id": "q-integrity-proof", "text": "What control proves that a posted entry has not been altered since posting?", "kind": "security", "answer_data": [ "integrity mechanism (hash, seal, WORM medium)", "verification procedure", "verification frequency" ] }, { "id": "q-storage-mode", "text": "Is the record held in non-rewriteable non-erasable form or under an audit-trail alternative, and who attests to that?", "kind": "validation", "answer_data": [ "storage mode declaration", "attesting party", "attestation document reference" ] } ], "data_elements": [ { "id": "de-change-event", "name": "Change event", "description": "Recorded modification or deletion attempt with actor, timestamp, and prior and new values.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-record-hash", "name": "Record integrity hash", "description": "Digest over the canonical form of the posted entry used to detect alteration.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "art-change-audit-log", "name": "Change audit log", "description": "Complete time-stamped trail of creations, modifications and deletions affecting entries, preserving originals.", "media_or_form": [ "append-only log", "WORM archive segment" ], "serial": true, "identity_strategy": "Log stream identifier plus monotonic sequence number issued by the recording system; each record keyed by the affected entry identifier and sequence position.", "source_refs": [ "SRC-006" ] } ], "inline_only_rationale": null } ] }, { "id": "lyr-authority-policy", "name": "Authority and accounting policy", "description": "Who is entitled to post, and under which recognition and measurement basis the posting is justified.", "source_refs": [ "SRC-005", "SRC-008", "SRC-012" ], "findings": [ { "id": "fnd-posting-authority", "name": "Posting authority, limits and segregation of duties", "description": "Entitlement to post to given accounts, periods and amounts, and the prohibited combinations of rights.", "source_refs": [ "SRC-005", "SRC-006", "SRC-012" ], "questions": [ { "id": "q-posting-permission", "text": "Who is permitted to post to which accounts, periods, amounts and ledgers?", "kind": "authority", "answer_data": [ "role or actor", "permitted account scope", "period scope", "amount limit" ] }, { "id": "q-segregation-duties", "text": "Which combinations of preparation, approval and posting rights are prohibited for a single actor?", "kind": "constraint", "answer_data": [ "prohibited right combinations", "enforcement mechanism", "documented exception process" ] }, { "id": "q-automated-posting-mandate", "text": "Which decision record authorises an automated interface to post without human approval, and how is it revoked?", "kind": "decision", "answer_data": [ "mandate reference", "scope and limits of the mandate", "revocation procedure and owner" ] } ], "data_elements": [ { "id": "de-authority-scope", "name": "Posting authority scope", "description": "Account, period, ledger and amount boundaries within which an actor may post.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-sod-rule", "name": "Segregation of duties rule", "description": "Declaration of right combinations that may not be held by one actor.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "art-posting-authority-matrix", "name": "Posting authority matrix", "description": "Authoritative mapping of roles to permitted accounts, periods, amount limits and prohibited right combinations.", "media_or_form": [ "authority matrix document", "access policy configuration" ], "serial": false, "identity_strategy": "Ledger identifier plus policy identifier plus version; effective period recorded as an attribute of each policy version.", "source_refs": [ "SRC-005", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "fnd-recognition-basis", "name": "Recognition, derecognition and measurement basis", "description": "Why the posting is permitted under the applicable framework and on what basis its amount was determined.", "source_refs": [ "SRC-008", "SRC-012", "SRC-014" ], "questions": [ { "id": "q-recognition-trigger", "text": "Which recognition criterion under the applicable framework triggers this posting?", "kind": "requirement", "answer_data": [ "element affected (asset, liability, equity, income, expense)", "recognition criterion cited", "framework reference" ] }, { "id": "q-measurement-basis", "text": "On which measurement basis is the amount determined, and what is the unit of account?", "kind": "measurement", "answer_data": [ "measurement basis", "unit of account", "valuation input source" ] }, { "id": "q-derecognition-event", "text": "Which event derecognises the asset or liability, and which posting records that removal?", "kind": "event", "answer_data": [ "derecognition trigger", "derecognising entry reference", "residual amount treatment" ] }, { "id": "q-estimate-flag", "text": "Does the amount rest on an estimate or judgement, and how is that flagged for audit attention?", "kind": "quality", "answer_data": [ "estimate indicator", "estimation method reference", "sensitivity or range where documented" ] } ], "data_elements": [ { "id": "de-element-category", "name": "Financial statement element category", "description": "Whether the line affects an asset, liability, equity, income or expense.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "de-measurement-basis", "name": "Measurement basis", "description": "Basis on which the amount was measured, such as historical cost or a current value basis.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-estimate-indicator", "name": "Estimate indicator", "description": "Flag that the amount involves significant estimation or judgement.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "The accounting policy and framework text are artifacts of the reporting-framework and policy models; this finding contributes only the per-entry classification and basis attributes plus a citation reference, which are inline data on the entry." }, { "id": "fnd-control-activities-override", "name": "Initiate, authorize, record and process", "description": "Controls must cover initiation, authorization, recording and processing of both automated and manual journal entries in the general ledger, subsidiary ledgers and other IT systems. Segregation of duties and dual control are expected except where a documented compensating control exists.", "source_refs": [ "SRC-016", "SRC-017", "SRC-005" ], "questions": [ { "id": "fnd-control-activities-override-q01", "text": "Who initiated this entry and who authorized it, and are those persons different under the segregation-of-duties rule?", "kind": "authority", "answer_data": [ "initiator-id", "authorizer-id", "sod-satisfied", "compensating-control" ] }, { "id": "fnd-control-activities-override-q02", "text": "Through which IT systems or interfaces was the entry recorded and processed, including subledger feeds?", "kind": "process", "answer_data": [ "source-system", "interface-id", "automated-control-ids" ] }, { "id": "fnd-control-activities-override-q03", "text": "Which roles may read the entry or its supporting evidence, and which fields are restricted as personal or commercially sensitive?", "kind": "access", "answer_data": [ "read-roles", "restricted-fields", "privacy-classification" ] }, { "id": "fnd-control-activities-override-q04", "text": "Was any control overridden, and what management or system override evidence exists?", "kind": "security", "answer_data": [ "override-flag", "override-actor", "override-reason", "override-approval" ] } ], "data_elements": [ { "id": "fnd-control-activities-override-data01", "name": "Initiator identifier", "description": "Person or system that initiated the entry.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-017" ] }, { "id": "fnd-control-activities-override-data02", "name": "Authorizer identifier", "description": "Person or system that authorized posting.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-017" ] }, { "id": "fnd-control-activities-override-data03", "name": "Segregation of duties satisfied", "description": "Whether initiator and authorizer are distinct as required.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-016" ] }, { "id": "fnd-control-activities-override-data04", "name": "Control override flag", "description": "Whether a control was overridden for this entry.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "fnd-control-activities-override-artifact01", "name": "Authorization record", "description": "Approval artefact or system workflow step proving authorization before post.", "media_or_form": [ "workflow approval", "signed voucher", "system authorization event" ], "serial": false, "identity_strategy": "Identify by authorization event identifier linked to the journal number.", "source_refs": [ "SRC-016", "SRC-017" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "bdl-assurance-quality", "name": "Validation, assurance and audit signals", "description": "Rules that make an entry acceptable, checks that make a population credible, and signals that make it suspicious.", "rationale": "Audit data standards pair field definitions with validation routines and completeness questions, and auditing standards require entries to be tested against defined risk characteristics; both are part of the operating surface an agent must serve.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005" ], "layers": [ { "id": "lyr-validation-rules", "name": "Validation and reconciliation", "description": "Acceptance rules for a single entry and assurance over the completeness of a population.", "source_refs": [ "SRC-003", "SRC-004" ], "findings": [ { "id": "fnd-structural-validation", "name": "Structural and referential validation", "description": "Which fields are required, which references must resolve and be active, and how schema conformance is judged.", "source_refs": [ "SRC-001", "SRC-003", "SRC-013" ], "questions": [ { "id": "q-mandatory-fields", "text": "Which fields are mandatory for an entry to be accepted, and which are conditionally mandatory?", "kind": "validation", "answer_data": [ "mandatory field list", "conditional rule expression", "rejection message catalogue" ] }, { "id": "q-referential-checks", "text": "Which referenced objects - account, period, currency, tax code, counterparty - must exist and be active at posting time?", "kind": "constraint", "answer_data": [ "reference type", "existence check", "activity or validity window check" ] }, { "id": "q-schema-conformance", "text": "Against which schema version is an incoming entry validated, and what happens to unknown fields?", "kind": "interoperability", "answer_data": [ "schema identifier and version", "unknown-field policy", "validation report location" ] } ], "data_elements": [ { "id": "de-validation-result", "name": "Validation result", "description": "Outcome of applying the rule set to an entry, with rule identifiers and severities.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-schema-version", "name": "Schema version applied", "description": "Identifier and version of the schema or profile the entry was validated against.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-013" ] } ], "artifacts": [ { "id": "art-validation-rule-set", "name": "Validation rule set", "description": "Versioned catalogue of structural, referential and business rules applied to entries, with severities.", "media_or_form": [ "rule specification", "executable validation profile", "schema plus assertion set" ], "serial": false, "identity_strategy": "Rule set namespace plus version identifier, bound to a named schema or export profile version.", "source_refs": [ "SRC-003", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "fnd-reconciliation-completeness", "name": "Reconciliation and population completeness", "description": "Whether postings agree to balances, whether the sequence is intact, and who attests that the extraction is complete.", "source_refs": [ "SRC-003", "SRC-004", "SRC-005" ], "questions": [ { "id": "q-trial-balance-agreement", "text": "Does the sum of postings agree to opening and closing account balances for the period?", "kind": "validation", "answer_data": [ "opening balance", "posting movement total", "closing balance", "difference and explanation" ] }, { "id": "q-sequence-gaps", "text": "Are there gaps or duplicates in the entry sequence, and how is each one explained?", "kind": "quality", "answer_data": [ "sequence range examined", "gap and duplicate list", "explanation per exception" ] }, { "id": "q-subledger-tie-out", "text": "How do subledger postings tie out to the general ledger control accounts?", "kind": "relationship", "answer_data": [ "subledger identifier", "control account reference", "reconciling item list" ] }, { "id": "q-completeness-attestation", "text": "Who attests that the extracted population of entries is complete for the stated scope and period?", "kind": "evidence", "answer_data": [ "attesting role and identity", "scope statement", "attestation timestamp" ] } ], "data_elements": [ { "id": "de-reconciliation-difference", "name": "Reconciliation difference", "description": "Residual difference between posting movement and balance change, with its explanation.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-population-scope", "name": "Population scope statement", "description": "Ledger, entity, period and filter criteria defining the extracted population.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-004" ] } ], "artifacts": [ { "id": "art-reconciliation-report", "name": "Reconciliation and completeness report", "description": "Report tying postings to balances, listing sequence exceptions and recording the completeness attestation.", "media_or_form": [ "reconciliation report", "control evidence package" ], "serial": true, "identity_strategy": "Ledger identifier plus scope statement plus run sequence number issued by the reconciling system; run instant is an attribute.", "source_refs": [ "SRC-003", "SRC-004" ] } ], "inline_only_rationale": null } ] }, { "id": "lyr-audit-risk-signals", "name": "Audit risk signals and evidence", "description": "Characteristics that make an entry worth investigating, and the supporting documentation behind it.", "source_refs": [ "SRC-005", "SRC-006" ], "findings": [ { "id": "fnd-risk-indicators", "name": "Journal entry risk indicators", "description": "The account, actor, timing and narrative characteristics used to select entries for fraud-focused testing.", "source_refs": [ "SRC-005", "SRC-003" ], "questions": [ { "id": "q-unusual-account-combination", "text": "Does the entry touch unrelated, unusual or seldom-used account combinations?", "kind": "quality", "answer_data": [ "account pair frequency statistic", "seldom-used account flag", "comparison population" ] }, { "id": "q-poster-anomaly", "text": "Was the entry posted by someone who does not normally post to those accounts?", "kind": "security", "answer_data": [ "poster identity", "historical posting profile", "deviation score" ] }, { "id": "q-timing-anomaly", "text": "Was the entry recorded at period end, after close, or outside normal business hours?", "kind": "temporal", "answer_data": [ "capture timestamp", "period-end proximity", "post-closing indicator" ] }, { "id": "q-narrative-quality", "text": "Does the entry carry a meaningful description, or is it blank, round-numbered or templated?", "kind": "evidence", "answer_data": [ "description presence and length", "round-number indicator", "template reuse count" ] } ], "data_elements": [ { "id": "de-risk-flag", "name": "Risk indicator flag", "description": "Named risk characteristic detected on an entry, with the rule that raised it.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-risk-score", "name": "Risk score", "description": "Composite score assigned to an entry by the selection routine.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "art-risk-scoring-report", "name": "Entry risk scoring report", "description": "Output of applying risk-indicator rules to a population, with selected entries and rationale.", "media_or_form": [ "analytics report", "selection working paper" ], "serial": true, "identity_strategy": "Population scope plus rule set version plus run sequence number; the report references entries by their master-system identifiers.", "source_refs": [ "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "fnd-supporting-evidence", "name": "Supporting evidence and documentation", "description": "Which documents substantiate the entry, how much is required, and how the link is protected.", "source_refs": [ "SRC-001", "SRC-005", "SRC-006", "SRC-012" ], "questions": [ { "id": "q-evidence-attachment", "text": "Which supporting documents are attached or referenced, and where are they held?", "kind": "evidence", "answer_data": [ "document type", "document identifier or archive number", "custodian and location" ] }, { "id": "q-evidence-sufficiency", "text": "What level of supporting evidence is required for each entry type and amount band?", "kind": "requirement", "answer_data": [ "entry type", "amount band", "required evidence set", "policy reference" ] }, { "id": "q-evidence-integrity", "text": "How is the link between entry and evidence protected against substitution, breakage or loss?", "kind": "security", "answer_data": [ "link integrity mechanism", "broken-link detection", "remediation procedure" ] } ], "data_elements": [ { "id": "de-evidence-ref", "name": "Evidence reference", "description": "Pointer to a supporting document, including its archive number where one exists.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-012" ] }, { "id": "de-evidence-digest", "name": "Evidence digest", "description": "Digest of the referenced evidence captured at attachment time.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "art-evidence-attachment", "name": "Supporting evidence attachment", "description": "Stored or referenced document substantiating the entry, with its digest and custody metadata.", "media_or_form": [ "scanned document", "electronic document", "external repository reference" ], "serial": false, "identity_strategy": "Document archive number or repository identifier issued by the custodian, bound to the entry identifier and verified by content digest.", "source_refs": [ "SRC-001", "SRC-006", "SRC-012" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "bdl-access-retention-interop", "name": "Access, retention and exchange", "description": "Who may see the entry, how long it must survive, and how it crosses system and jurisdictional boundaries.", "rationale": "Postings are simultaneously confidential commercial data, statutorily retained records, and mandatory disclosures to auditors and tax authorities; these obligations pull in different directions and must be modelled explicitly rather than assumed.", "source_refs": [ "SRC-001", "SRC-006", "SRC-012", "SRC-013" ], "layers": [ { "id": "lyr-access-confidentiality", "name": "Access and confidentiality", "description": "Default and privileged read rights, mandated third-party access, and personal data carried inside entries.", "source_refs": [ "SRC-006", "SRC-001" ], "findings": [ { "id": "fnd-access-control", "name": "Access, mandated disclosure and personal data in entries", "description": "Who may read entries, what auditors and authorities may demand, and how personal data inside entries is handled.", "source_refs": [ "SRC-001", "SRC-006", "SRC-012", "SRC-013" ], "questions": [ { "id": "q-default-visibility", "text": "Who may read a posted entry by default, and at what granularity - header, line, amount, narrative?", "kind": "access", "answer_data": [ "default role set", "granularity per role", "denial default statement" ] }, { "id": "q-privileged-access", "text": "Which roles may see restricted amounts, counterparties or narratives, and under what conditions?", "kind": "security", "answer_data": [ "privileged role list", "condition or approval required", "time limit on elevated access" ] }, { "id": "q-regulator-access", "text": "What obligation exists to furnish entries promptly to auditors, tax authorities or regulators, and through whom?", "kind": "authority", "answer_data": [ "obligation source", "responsible officer or third-party undertaking", "furnishing format and deadline" ] }, { "id": "q-personal-data-presence", "text": "Which personal data can appear in entry narratives, counterparty fields and attachments?", "kind": "privacy", "answer_data": [ "personal data field inventory", "free-text risk assessment", "minimisation control" ] }, { "id": "q-erasure-conflict", "text": "How is an erasure request reconciled with statutory retention and audit-trail immutability?", "kind": "exception", "answer_data": [ "conflicting obligation citations", "resolution decision", "record of the decision and its authoriser" ] } ], "data_elements": [ { "id": "de-confidentiality-class", "name": "Confidentiality classification", "description": "Sensitivity class assigned to the entry or specific fields.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-access-event", "name": "Access event", "description": "Recorded read, export or disclosure action with actor, scope and timestamp.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-personal-data-field", "name": "Personal data field marker", "description": "Marker identifying a field that may carry personal data about a natural person.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "art-access-log", "name": "Access and disclosure log", "description": "Log of who read, exported or disclosed entries, at what scope and under which authority.", "media_or_form": [ "append-only access log", "disclosure register" ], "serial": true, "identity_strategy": "Log stream identifier plus monotonic sequence; each record keyed to the accessing actor and the entry or population identifier accessed.", "source_refs": [ "SRC-006" ] } ], "inline_only_rationale": null } ] }, { "id": "lyr-retention-disposal", "name": "Retention and disposal", "description": "How long entries and their evidence must survive, in what accessibility tier, and how disposal is proven.", "source_refs": [ "SRC-006", "SRC-012" ], "findings": [ { "id": "fnd-retention-legal-hold", "name": "Retention schedule, legal hold and lawful disposal", "description": "The applicable retention clock, accessibility obligations during it, hold mechanics and evidence of disposal.", "source_refs": [ "SRC-006", "SRC-012", "SRC-001" ], "questions": [ { "id": "q-retention-period", "text": "For how long must this entry and its evidence be retained, under which rule, and when does the clock start?", "kind": "retention", "answer_data": [ "retention duration", "governing rule citation", "clock start event" ] }, { "id": "q-accessibility-tier", "text": "Which portion of the retention period requires immediately accessible storage rather than archival storage?", "kind": "constraint", "answer_data": [ "accessible period duration", "access latency target", "storage tier declaration" ] }, { "id": "q-legal-hold", "text": "How is a legal hold applied to entries, and what does it suspend?", "kind": "exception", "answer_data": [ "hold identifier and scope", "suspended operations", "hold release authority" ] }, { "id": "q-disposal-evidence", "text": "What record proves lawful disposal at the end of the retention period?", "kind": "evidence", "answer_data": [ "disposal certificate reference", "approving role", "scope disposed and method" ] } ], "data_elements": [ { "id": "de-retention-rule-ref", "name": "Retention rule reference", "description": "Citation of the statutory or contractual rule fixing the retention duration.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006", "SRC-012" ] }, { "id": "de-retention-expiry", "name": "Retention expiry date", "description": "Date on which the retention obligation lapses, derived from the clock start and duration.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-012" ] }, { "id": "de-legal-hold-ref", "name": "Legal hold reference", "description": "Identifier of a hold suspending disposal for the entry or population.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "art-retention-hold-register", "name": "Retention and legal hold register", "description": "Register of retention classes, expiry calculations, active holds and completed disposals for ledger records.", "media_or_form": [ "records retention schedule", "hold register", "disposal certificate set" ], "serial": false, "identity_strategy": "Retention class identifier plus governing rule citation plus version; individual holds identified by hold identifier issued by the records custodian.", "source_refs": [ "SRC-006", "SRC-012" ] } ], "inline_only_rationale": null } ] }, { "id": "lyr-interoperability-exchange", "name": "Exchange profiles and mapping", "description": "The formats entries must be delivered in and the code-list mappings and conflicts those formats impose.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-013" ], "findings": [ { "id": "fnd-exchange-profiles", "name": "Export profiles, mapping and profile conflicts", "description": "Which exchange profile applies, what it cannot carry, how local codes map to standard ones, and which profile wins on conflict.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-010", "SRC-013" ], "questions": [ { "id": "q-target-profile", "text": "Which exchange profile does the receiving authority or auditor require, and in which version?", "kind": "interoperability", "answer_data": [ "profile name", "profile version", "receiving authority identifier" ] }, { "id": "q-profile-completeness", "text": "Which model fields have no home in the target profile, and how is that loss recorded?", "kind": "quality", "answer_data": [ "unmapped field list", "loss handling decision", "supplementary delivery mechanism" ] }, { "id": "q-file-scope", "text": "What population, period and entity scope does an export assert, and how is that asserted in the file header?", "kind": "composition", "answer_data": [ "header scope fields", "selection criteria", "control totals asserted" ] }, { "id": "q-account-mapping", "text": "How are local account numbers mapped to standard or statutory account codes for the profile?", "kind": "interoperability", "answer_data": [ "local account code", "standard account code", "mapping table version and owner" ] }, { "id": "q-mapping-conflict", "text": "Where do required profiles disagree in semantics, and which one prevails?", "kind": "exception", "answer_data": [ "conflicting profiles and elements", "semantic difference description", "precedence decision and its owner" ] } ], "data_elements": [ { "id": "de-export-profile", "name": "Export profile identifier", "description": "Name and version of the exchange profile used for a delivery.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-account-mapping", "name": "Account code mapping", "description": "Mapping from a local account code to a standard or statutory account code.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-002" ] }, { "id": "de-unmapped-field", "name": "Unmapped field record", "description": "Model field with no counterpart in the target profile, with its handling decision.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "art-audit-file-export", "name": "Audit or tax file export", "description": "Delivered file containing header, master data, entries and control totals in a named profile version.", "media_or_form": [ "tax audit file", "ledger taxonomy instance", "delimited audit data file", "statement message set" ], "serial": true, "identity_strategy": "Producing system identifier plus ledger plus asserted period plus monotonic export sequence number; content digest recorded for integrity, filename dates never used as identity.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-013" ] }, { "id": "art-code-mapping-table", "name": "Code and account mapping table", "description": "Versioned mapping from local codes to standard account, tax and transaction code lists required by profiles.", "media_or_form": [ "mapping table", "crosswalk specification" ], "serial": false, "identity_strategy": "Source code list plus target code list plus mapping version, each issued under a named owning authority.", "source_refs": [ "SRC-002", "SRC-013" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "fn-draft-entry", "name": "Draft a posting", "description": "Create an unposted entry with header context and candidate lines, derived from a source event or entered manually.", "inputs": [ "ledger identifier", "source event or manual input", "proposed lines with account, direction, amount, currency", "preparer identity" ], "outputs": [ "draft entry with assigned draft identifier", "derivation metadata", "initial validation findings" ], "preconditions": [ "ledger profile resolved", "target accounts exist and are active", "preparer holds capture rights for the ledger" ], "effects": [ "draft record created in mutable state", "change audit log opened for the draft", "no effect on account balances" ], "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "fn-validate-entry", "name": "Validate an entry", "description": "Apply structural, referential, balancing and business rules to an entry and report severities.", "inputs": [ "entry (draft or inbound)", "validation rule set version", "reference data snapshot" ], "outputs": [ "validation result set with rule identifiers and severities", "pass or fail determination" ], "preconditions": [ "rule set version resolvable", "referenced code lists and accounts retrievable at the entry's effective date" ], "effects": [ "validation results attached to the entry", "blocking failures prevent transition to posted" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-013" ] }, { "id": "fn-post-entry", "name": "Post an entry to the ledger", "description": "Commit a validated, authorised entry to the ledger of record and make it immutable.", "inputs": [ "validated entry", "approval record", "target fiscal period" ], "outputs": [ "posted entry with authoritative master-system identifier", "posting timestamp", "balance movement events" ], "preconditions": [ "debits equal credits at the declared balancing scope", "target period is open for the posting role", "approver differs from preparer where segregation rules require it" ], "effects": [ "entry becomes immutable except through reversal", "account balances move", "integrity hash and audit trail entry written" ], "source_refs": [ "SRC-002", "SRC-005", "SRC-006" ] }, { "id": "fn-reverse-entry", "name": "Reverse or correct a posted entry", "description": "Create a linked reversing or replacement entry rather than altering the original record.", "inputs": [ "original entry identifier", "correction method", "reason code", "authoriser identity", "target period" ], "outputs": [ "reversing entry", "optional replacement entry", "bidirectional correction links" ], "preconditions": [ "original entry is in posted state", "authoriser holds reversal rights", "target period is open or a prior-period adjustment route is authorised" ], "effects": [ "original record left unaltered", "reversing and replacement entries posted and linked", "correction reason recorded in the audit trail" ], "source_refs": [ "SRC-002", "SRC-005", "SRC-006" ] }, { "id": "fn-translate-currency", "name": "Translate a posting to reporting currencies", "description": "Derive functional or group reporting amounts for a line from a governed exchange rate.", "inputs": [ "line amount and transaction currency", "target currency role", "rate table and rate date" ], "outputs": [ "translated amount per currency role", "applied rate with its source and date" ], "preconditions": [ "rate exists for the currency pair at the applicable rate date", "rounding rule declared for the target currency" ], "effects": [ "translated amounts and rate provenance stored on the line", "rounding difference routed to the declared account" ], "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "fn-attach-evidence", "name": "Attach supporting evidence", "description": "Bind a supporting document to an entry with a digest and custody metadata.", "inputs": [ "entry identifier", "evidence reference or content", "custodian identifier" ], "outputs": [ "evidence link with digest", "updated evidence sufficiency assessment" ], "preconditions": [ "evidence sufficiency policy resolved for the entry type and amount band", "custodian retention obligations at least match the entry's" ], "effects": [ "evidence link recorded and digest stored", "broken-link detection scope extended to the new link" ], "source_refs": [ "SRC-001", "SRC-006", "SRC-012" ] }, { "id": "fn-reconcile-trial-balance", "name": "Reconcile postings to balances", "description": "Verify that posting movements explain the change in account balances for a scope and period, and analyse sequence integrity.", "inputs": [ "population scope statement", "opening and closing balances", "entry population" ], "outputs": [ "reconciliation report", "difference list with explanations", "sequence gap and duplicate list" ], "preconditions": [ "population extraction complete for the declared scope", "opening balances agreed to the prior period close" ], "effects": [ "reconciliation report produced and retained", "unexplained differences raised as exceptions" ], "source_refs": [ "SRC-003", "SRC-004" ] }, { "id": "fn-screen-risk-indicators", "name": "Screen entries for risk indicators", "description": "Score a population of entries against fraud-risk characteristics and select entries for testing.", "inputs": [ "entry population", "risk rule set version", "historical posting profiles" ], "outputs": [ "risk flags and scores per entry", "selected sample with selection rationale" ], "preconditions": [ "population completeness attested", "actor posting history available for profiling" ], "effects": [ "risk scoring report produced", "selected entries queued for evidence inspection" ], "source_refs": [ "SRC-005" ] }, { "id": "fn-close-period", "name": "Close an accounting period", "description": "Transition a fiscal period to a closed state and record the closing balances and residual items.", "inputs": [ "ledger identifier", "fiscal period", "closing checklist results", "closing authority identity" ], "outputs": [ "period close record", "closing balances", "list of permitted post-closing routes" ], "preconditions": [ "all draft entries for the period resolved or explicitly carried forward", "reconciliation completed for the period" ], "effects": [ "period state changed to closed", "further postings restricted to authorised post-closing routes", "close event written to the audit trail" ], "source_refs": [ "SRC-003", "SRC-005", "SRC-012" ] }, { "id": "fn-export-audit-file", "name": "Export an audit or tax file", "description": "Produce a profile-conformant export of a declared entry population with control totals and mapping applied.", "inputs": [ "population scope statement", "target profile and version", "code and account mapping table version" ], "outputs": [ "audit file export artifact", "asserted control totals", "unmapped field record" ], "preconditions": [ "mapping table covers all codes present in the population", "profile version accepted by the receiving authority", "population completeness attested" ], "effects": [ "export artifact produced with content digest", "export event logged including scope and requester", "unmapped fields recorded as a known loss" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-013" ] }, { "id": "fn-grant-audit-access", "name": "Grant scoped auditor or authority access", "description": "Provision time-bounded, scope-limited read or export access for an auditor, tax authority or regulator.", "inputs": [ "requesting party identity and authority basis", "requested scope and period", "approving officer identity" ], "outputs": [ "access grant with scope and expiry", "access log entries for every exercised right" ], "preconditions": [ "authority basis verified", "scope no broader than the stated obligation", "confidentiality and personal data controls applied to the scope" ], "effects": [ "grant issued and recorded", "all reads and exports under the grant logged", "grant expires automatically at the declared time" ], "source_refs": [ "SRC-006", "SRC-012" ] }, { "id": "fn-apply-legal-hold", "name": "Apply or release a legal hold", "description": "Suspend or resume disposal for a defined population of entries and their evidence.", "inputs": [ "hold identifier and legal basis", "population scope", "hold authority identity" ], "outputs": [ "hold record", "suspended disposal schedule", "release record on lifting" ], "preconditions": [ "population scope resolvable to entry identifiers", "hold authority verified" ], "effects": [ "disposal suspended for the scope regardless of retention expiry", "hold and release events written to the audit trail" ], "source_refs": [ "SRC-006" ] }, { "id": "fn-authorize-entry", "name": "Authorize journal entry", "description": "Record the authorizer distinct from the initiator and attach the authorization event required before posting.", "inputs": [ "journal identifier", "authorizer identity", "authorization decision", "segregation-of-duties policy" ], "outputs": [ "authorization record", "sod-satisfied flag" ], "preconditions": [ "Entry exists in a pre-posted state", "Authorizer is permitted for the book and amount" ], "effects": [ "Attaches an authorization artefact", "May block posting if segregation of duties fails" ], "source_refs": [ "SRC-016", "SRC-017" ] }, { "id": "fn-reject-closed-period", "name": "Reject or exception-post to closed period", "description": "Block posting to a closed period unless a documented exception grant exists for adjusting entries.", "inputs": [ "book code", "fiscal period", "entry type", "exception grant if any" ], "outputs": [ "accept or reject", "exception reference" ], "preconditions": [ "Period status is known for the book" ], "effects": [ "Prevents unauthorized closed-period posting", "Records exception use when a grant is consumed" ], "source_refs": [ "SRC-017", "SRC-016" ] }, { "id": "fn-apply-bank-transaction-code", "name": "Classify and reconcile a bank-booked entry", "description": "Apply an ISO 20022 bank transaction code to a servicer-booked cash entry so it can be routed to the correct sub-ledger counterpart journal.", "inputs": [ "bank statement entry", "bank transaction code", "candidate account" ], "outputs": [ "classified entry", "proposed counterpart posting", "reconciliation status" ], "preconditions": [ "Entry carries or can be assigned a bank transaction code", "Target sub-ledger accounts are known" ], "effects": [ "Does not itself balance the books", "Feeds a subsequent balanced posting" ], "source_refs": [ "SRC-019", "SRC-024" ] } ], "composition": [ { "target": "WM-ECO-015 Financial Account", "relation": "CHILD", "purpose": "The account is the container that holds postings; this model supplies the postings and takes account identity, status and balance semantics from the parent rather than redefining them.", "required": true, "source_refs": [ "SRC-001", "SRC-003", "SRC-004" ] }, { "target": "WM-ECO-009 Payment", "relation": "REFERENCE", "purpose": "A payment produces one or more postings; the entry references the payment and reads its booking status and finality rather than modelling instruction or clearing mechanics.", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] }, { "target": "Invoice / commercial source document model (sibling, identifier not yet assigned)", "relation": "REFERENCE", "purpose": "Supplies the evidencing document referenced by the entry, kept in a separate section in audit file formats and under its own custody and retention.", "required": false, "source_refs": [ "SRC-001", "SRC-013" ] }, { "target": "Party / legal entity model (counterparty and reporting entity)", "relation": "REFERENCE", "purpose": "Resolves reporting entity and counterparty references through governed identifiers such as the ISO 17442 Legal Entity Identifier.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "Currency and unit-of-measure registry model", "relation": "REFERENCE", "purpose": "Supplies governed currency codes, minor units and unit-of-measure codes used by line amounts and quantities.", "required": true, "source_refs": [ "SRC-002", "SRC-010" ] }, { "target": "Fiscal calendar and accounting period model", "relation": "REFERENCE", "purpose": "Defines fiscal years, period boundaries and period states that the entry's effective date resolves against.", "required": true, "source_refs": [ "SRC-003", "SRC-012" ] }, { "target": "Records retention and legal hold mixin", "relation": "MIX-IN", "purpose": "Contributes retention class, expiry calculation, accessibility tier and hold semantics rather than duplicating them inside the entry model.", "required": true, "source_refs": [ "SRC-006", "SRC-012" ] }, { "target": "Actor, role and authorisation mixin", "relation": "MIX-IN", "purpose": "Contributes actor identity, delegation and entitlement structures used by preparer, approver and posting-authority findings.", "required": true, "source_refs": [ "SRC-005", "SRC-006" ] }, { "target": "OECD Standard Audit File - Tax, Version 2.0", "relation": "ALIGN", "purpose": "Alignment target for export structure, control totals and the separation of master files, general ledger entries and source documents. National profiles constrain and extend it; conformance is asserted only per delivered profile version.", "required": false, "source_refs": [ "SRC-001", "SRC-013" ] }, { "target": "XBRL Global Ledger Taxonomy Framework", "relation": "ALIGN", "purpose": "Alignment target for entry header and detail representation, multi-currency handling and explicit mapping to financial reporting taxonomies.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "AICPA Audit Data Standards - General Ledger Standard and ISO 21378 audit data collection", "relation": "ALIGN", "purpose": "Alignment targets for system-independent field definitions, actor and date fields, and validation and completeness routines used by auditors.", "required": false, "source_refs": [ "SRC-003", "SRC-004" ] }, { "target": "ISO 20022 Bank-to-Customer Cash Management message definitions", "relation": "ALIGN", "purpose": "Alignment target for account servicer entry semantics: credit/debit indicator, reversal indicator, booking status, booking date and value date, and bank transaction codes.", "required": false, "source_refs": [ "SRC-010" ] }, { "target": "IFRS Conceptual Framework for Financial Reporting", "relation": "ALIGN", "purpose": "Supplies element definitions, recognition and derecognition criteria and measurement bases that justify whether and at what amount a posting may be made.", "required": false, "source_refs": [ "SRC-008" ] }, { "target": "ISO/IEC 15944-4 accounting and economic (REA) ontology", "relation": "ALIGN", "purpose": "Boundary alignment separating business-level economic events, resources and agents from the accounting artifact modelled here. Asserted at catalogue level only and flagged as an evidence gap.", "required": false, "source_refs": [ "SRC-014" ] }, { "target": "Audit engagement and assurance evidence model", "relation": "EXTEND", "purpose": "Extends the entry with audit selection, testing and working-paper context without importing audit methodology into the ledger model.", "required": false, "source_refs": [ "SRC-005" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "Name the authoritative ledger system of record for each ledger, its identifier scheme, and the scope over which entry identifiers are unique and never reused, before any entry instance is created.", "Publish, as versioned artifacts, the chart of accounts reference, journal and entry-type code lists, tax code table, analytical dimension value sets and the account mapping table used for statutory export.", "Declare per ledger the accounting framework, functional currency, fiscal calendar, balancing scope and rounding rule, and the retention class and regulator access obligations that apply in each jurisdiction of operation.", "Declare the storage mode for posted entries - non-rewriteable non-erasable, or an audit-trail alternative - and name the officer or third party who attests to it and who is obliged to furnish records on request." ], "namespace_guidance": "Namespace entries under the owning reporting entity and ledger, for example urn:{dimension}:{entity-identifier}:ledger:{ledger-id}:entry:{entry-id}, with line identity expressed as a fragment of the entry namespace. Code lists are namespaced by their issuing authority and version, never by the adopting Dimension, so that OECD, national tax authority, ISO 20022 external code set and local values remain distinguishable after export. Never reuse an entry identifier across ledgers or fiscal years, and never encode a date or period into an identifier as a disambiguator.", "registry_links": [ "Registry entry vr.wm-eco-016 in the world-model record plane, nav path NAV.SOC.ECO.TXN", "Parent WM-ECO-015 Financial Account for account identity, status and balances", "WM-ECO-009 Payment for transfer, booking status and finality references", "Global LEI Index for reporting entity and counterparty identifiers under ISO 17442", "National SAF-T schema and code-list repositories for the profile version in force in each jurisdiction of filing" ] }, "canon_and_patch": { "canonicalization_rules": [ "Amounts are exact decimals with a declared scale and an explicit currency code; binary floating point is never used, and the pair (magnitude, credit/debit indicator) is authoritative with any signed representation derived from it, never the reverse.", "Instants are normalised to RFC 3339 with seconds and an explicit offset while preserving the original local offset; pure accounting dates are kept as full-date values and are never widened into midnight instants.", "Coded values are stored as scheme-qualified pairs of code list identifier, version and code value, so that a code retains meaning after export into a different profile.", "Lines are canonically ordered by line identifier, and object keys are canonically ordered before hashing, so that the integrity digest of a posted entry is reproducible across storage projections.", "Control totals are recomputed from the canonical lines rather than copied forward, and a mismatch between asserted and recomputed totals is an error, not a warning." ], "patch_rules": [ "Posted entries are append-only: any change to amount, direction, account, currency, effective date or fiscal period is effected by a new reversing or replacement entry that is linked bidirectionally to the original, never by an in-place edit.", "Drafts may be patched freely before posting, but every patch records actor, timestamp, reason and before-and-after values in the change audit log.", "Metadata-only patches to a posted entry - narrative enrichment, added cross-references, added dimension values where policy permits - are allowed only where the audit trail preserves both the original and the modified record and the entry's integrity digest chain is extended rather than overwritten.", "A patch request that would break the balancing invariant, target a hard-closed period, or contradict an active legal hold is rejected and the rejection itself is logged.", "Deletion of a posted entry is never a patch operation; disposal occurs only through the retention and legal hold path with a disposal record." ], "compatibility_rules": [ "Adding optional fields, new code list values or new analytical dimensions is a minor change; consumers must ignore unknown optional fields rather than reject the record.", "Changing the balancing scope, the meaning of an existing code, the direction convention, identifier scope or a validation severity is a breaking change and requires a major version with a stated migration path.", "Export profile versions are pinned per delivery and recorded in the export artifact; a profile upgrade never silently reinterprets previously delivered files.", "Deprecations are announced at least one major version ahead and carry a replacement mapping; a deprecated element remains readable for the full statutory retention period of the records that used it." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the ledger system of record - for example the ERP journal identifier plus line number, or the audit-file transaction and record identifier - is used first, qualified by ledger and reporting entity.", "Governed global identifier or IRI where one exists and is authoritative for the object, such as the ISO 20022 end-to-end or account-servicer reference for a settled transfer, or an ISO 17442 Legal Entity Identifier for the entity namespace.", "UUID or ULID minted by the adopting Dimension, used only where neither of the above exists, recorded explicitly as a surrogate together with its minting authority and the natural key it stands for.", "A date, period, amount, description or filename is never an identifier; such values may be recorded as attributes and used for search, but must not carry identity." ], "timestamp_rule": "All instants are recorded as RFC 3339 date-time values with explicit seconds and an explicit UTC offset or 'Z'; the original local offset is preserved rather than normalised away, and '-00:00' is used only where the local offset is genuinely unknown. Event time and observation or ingestion time are recorded separately whenever they can differ: accounting effective date, posting date, value date and settlement finality instant are event times, while the system entry timestamp, extraction timestamp, export timestamp and audit-capture timestamp are observation or ingestion times. Values that are calendar accounting dates with no meaningful instant are stored as full-date values and typed as dates, never converted to midnight timestamps or shifted by an offset.", "serial_naming_rule": "Serial artifacts - batch control totals, period close records, statement entries, reconciliation and risk reports, audit file exports, audit and access log segments - are named {ledger-id}-{artifact-kind}-{fiscal-period-or-scope}-{monotonic-sequence}, where the sequence is issued by the producing system of record. The sequence, not any date in the name, is the ordering key; gaps and duplicates in the sequence must be explicitly explained rather than silently accepted, and re-issued artifacts take a new sequence number and reference the superseded one.", "integrity_rule": "Every exported or archived artifact carries a content digest over its canonical form, the control totals it asserts (entry count, total debit, total credit), and the identity of the producing system and actor. Posted entries are stored either in non-rewriteable, non-erasable form or under a complete time-stamped audit trail that preserves both the original and every modified version together with the identity of the person or process making the change. Any artifact failing digest or control-total verification is quarantined and reported, never silently re-derived or overwritten; re-derivation produces a new artifact with a new sequence number that references the failed one." }, "policies": [ "Entries are immutable once posted; every correction is a new linked entry, and the ability to alter or delete a posted record is treated as a control failure rather than a feature.", "No entry is accepted unless debits equal credits at the declared balancing scope and every referenced account, period, currency and code resolves and is valid at the entry's effective date.", "Preparation, approval and posting rights are separated; where a single actor legitimately holds more than one, the exception is documented, time-bounded and subject to compensating review.", "Event time is never conflated with capture time; postings dated earlier than their capture require named authority and are flagged for audit selection.", "Access is deny-by-default and least-privilege, but statutory furnishing obligations to auditors and authorities override commercial confidentiality within the scope of the obligation and are logged as disclosures.", "Retention obligations and active legal holds override any deletion, minimisation or erasure request; conflicts are resolved by a recorded decision naming the conflicting obligations and the authorising officer.", "Posted journal entries are immutable; corrections use reversing or restating entries", "Debit totals must equal credit totals in the balancing currency before a header may post as a journal", "Default access is deny; create and authorize are separate roles; read of personal-data lines is additionally restricted", "Closed-period posting is forbidden without an explicit exception grant", "Journal populations used for audit or tax export must be tested for completeness before sampling or filing" ], "crud": { "read": [ "Resolve a posted entry with its lines, dates, actors, classification and correction links by master-system identifier.", "Query an entry population by ledger, period, account, dimension, actor or risk flag, returning a scope statement alongside the results.", "Retrieve the change audit log, integrity digest and storage-mode attestation for an entry.", "Export a scoped population in a named profile version with recomputed control totals." ], "create": [ "Create a draft entry from a source event or manual input, with derivation metadata and preparer identity.", "Post a validated and approved entry, minting or adopting its authoritative identifier and writing balance movements.", "Create a reversing or replacement entry linked bidirectionally to an original.", "Create serial control artifacts: batch control totals, period close records, reconciliation and risk reports, exports." ], "update": [ "Patch a draft entry, recording actor, timestamp, reason and before-and-after values.", "Apply permitted metadata-only enrichment to a posted entry where the audit trail preserves original and modified versions.", "Update lifecycle state along permitted transitions only, including period state changes made by the closing authority.", "Apply or release a legal hold across a defined population." ], "delete": [ "Deletion of a posted entry is prohibited; the only lawful removal path is disposal at the end of the retention period, blocked while any hold is active.", "Abandoned drafts may be disposed of under the declared draft retention rule, with the disposal recorded.", "Disposal executes only against a retention class with an expired clock, an approving role and a disposal certificate naming scope and method.", "Erasure requests touching personal data inside entries are resolved by recorded decision; they never silently remove or rewrite ledger records or audit trail entries." ] }, "roles": [ { "name": "Ledger owner / financial controller", "responsibilities": [ "Declares the ledger profile: framework, functional currency, fiscal calendar, balancing scope and rounding rule.", "Owns the posting authority matrix and approves documented segregation-of-duties exceptions.", "Authorises period close and prior-period adjustment routes." ] }, { "name": "Preparer / posting agent", "responsibilities": [ "Creates draft entries with complete derivation metadata and meaningful descriptions.", "Resolves validation failures before submitting for approval.", "Attaches supporting evidence required for the entry type and amount band." ] }, { "name": "Approver / reviewer", "responsibilities": [ "Verifies balancing, period, account and evidence sufficiency before release.", "Records approval with identity, timestamp and the rule relied upon.", "Authorises reversals with a reason code and refuses in-place alteration requests." ] }, { "name": "Auditor (internal or external)", "responsibilities": [ "Requests complete entry populations with a scope statement and completeness attestation.", "Applies risk-indicator screening and inspects supporting evidence for selected entries.", "Verifies the storage mode, audit trail integrity and reconciliation to balances." ] }, { "name": "Tax authority or regulator", "responsibilities": [ "Specifies the required export profile, version and filing scope.", "Exercises statutory access rights within a logged, scope-limited grant.", "Rules on profile conflicts and national code-list precedence." ] }, { "name": "Records custodian / platform steward", "responsibilities": [ "Operates non-rewriteable storage or the audit-trail alternative and maintains its attestation.", "Maintains retention classes, expiry calculation, legal holds and disposal certificates.", "Maintains code lists, mapping tables and schema versions, and verifies artifact digests and control totals." ] } ], "access": { "default_rule": "Deny by default. Read access to a posted entry is granted only to roles with an explicit entitlement covering that ledger, period and account scope, at the finest granularity the request permits; export and disclosure require a separate, explicitly scoped and time-bounded grant.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Statutory furnishing obligations to auditors, tax authorities and regulators override commercial confidentiality within the scope of the obligation, exercised through a named responsible officer or third-party undertaking.", "Entries in restricted journals such as payroll or litigation provisions may be masked at line or narrative granularity for roles that otherwise hold ledger-wide read access.", "Break-glass access for incident investigation is permitted only with a named approver, an expiry, and mandatory retrospective review.", "Personal data inside narratives and counterparty fields may be redacted for analytical consumers, provided the unredacted record remains intact for statutory and audit access.", "Legal hold suspends any access restriction that would prevent preservation, but does not by itself widen read access.", "Break-glass read for a named incident with time-bounded grant and full audit log", "Closed-period posting by a named controller with an exception grant", "Auditor read of the full population extract for a scoped engagement" ], "audit_requirements": [ "Every read, query, export and disclosure of entry data is logged with actor identity, scope, authority basis and RFC 3339 timestamp.", "Every grant, elevation, break-glass use and expiry is logged and retrospectively reviewed by a role independent of the requester.", "Every modification or deletion attempt against a posted record is logged with before-and-after values, whether or not it succeeded.", "Access logs are themselves retained under the ledger's retention class and protected by the same storage-mode and integrity controls as the entries they describe.", "Log initiator, authorizer, poster, timestamps, source system and control totals for every posted entry", "Retain completeness tests of journal populations used in audits", "Record overrides, exclusions from fraud-criteria testing, and legal holds" ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID", "Registry ID", "Owning Dimension and ledger scope", "Identity scheme and uniqueness scope", "Retention and legal hold policy URL", "Access and disclosure policy URL", "Export profile versions in force", "Code list and mapping table URLs" ], "read_order": [ "AGENTS.md - resolve model identity, type, and the specification, storage, interface and process URLs before any other action", "Specification URL - bundles, layers, findings and questions, plus scope and boundary notes against sibling models", "Identity scheme and uniqueness scope - establish how entries and lines are named before creating or resolving any instance", "Storage type URL - learn the storage projection, storage mode (non-rewriteable or audit-trail alternative) and canonicalization rules", "Interface URL - learn the read, create, update and disposal operations actually exposed, and their preconditions", "Processes URL - learn drafting, validation, posting, correction, close, export, access-grant and disposal procedures", "Access and disclosure policy URL and retention policy URL - determine what may be read, exported or disposed of before acting" ] } }, "coverage": { "claim": "Synthesis takes the Claude result as base: its six boundary notes assign every neighbouring object to a named sibling model (WM-ECO-015 account, WM-ECO-009 payment, invoice, reporting, party, REA ontology), and each finding without an artifact carries an explicit inline-only rationale naming the record or sibling model that already holds the data. The merged model covers identity and classification, header-to-line composition and the balancing invariant, monetary/FX and tax measurement, time roles and fiscal period, lifecycle and correction, provenance, authority and control, validation, reconciliation and audit risk signals, and access, retention and exchange for one accounting posting. Two Grok findings and three Grok functions close named gaps: top-side adjustments made outside the general ledger, management override of controls, explicit authorization as an operation, closed-period exception posting, and reconciliation of servicer-booked cash entries into counterpart journals. Coverage is asserted only for the operating surface an agent needs to create, validate, post, correct, audit, retain and export an entry under the standards actually read; it is alignment, not conformance, and it is not universal across jurisdictions, accounting frameworks, ledger products or distributed-ledger postings. Privacy remains a declared gap.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Entry and line identification, uniqueness scope, non-reuse and external reference resolution are modelled explicitly; identity priority puts the ledger system of record first and forbids dates, amounts and filenames as identifiers." }, { "dimension": "lifecycle", "status": "covered", "notes": "Draft to approved to posted to reversed states, the immutability point, provisional versus booked postings, abandoned drafts and period close are all covered; the exact state vocabulary is Dimension-specific and must be declared per ledger." }, { "dimension": "relationships", "status": "covered", "notes": "Links to account, payment, source document, counterparty, parallel ledger postings, corrections and subledger control accounts are all modelled as references, with the owning model named in each case." }, { "dimension": "temporal", "status": "covered", "notes": "Document, effective, posting, value, tax point, approval, capture and finality times are separated; the timestamp rule mandates RFC 3339 with seconds and explicit offset and distinguishes event time from observation or ingestion time." }, { "dimension": "provenance", "status": "covered", "notes": "Source system, interface, batch, source document, posting rule version, preparer, approver, service-account attribution and replay determinism are covered, with the change audit log as the authoritative history." }, { "dimension": "ownership", "status": "covered", "notes": "Reporting entity and business unit ownership of the ledger, accountable human owner behind service accounts, and custodial ownership of evidence and archives are addressed; group-level beneficial ownership is left to the party model." }, { "dimension": "validation", "status": "covered", "notes": "Structural, referential, balancing and business rule validation, control totals, trial balance agreement, sequence gap analysis, subledger tie-out and completeness attestation are all modelled with a versioned rule-set artifact." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default read, granularity per role, privileged and break-glass access, mandated auditor and authority access through a named officer or third-party undertaking, and mandatory access logging are covered at bundle, layer, finding and artifact scope." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention duration and clock start, accessibility tier during retention, legal hold mechanics, prohibition on deleting posted entries, draft disposal and disposal evidence are covered; concrete durations cited are US broker-dealer and UK company law and do not generalise." }, { "dimension": "interoperability", "status": "covered", "notes": "Export profiles, profile versioning, unmapped-field loss recording, account and code-list mapping, profile conflict precedence and round-trip verification are modelled, with tax audit file, ledger taxonomy, audit data standard and statement message semantics as alignment targets." }, { "dimension": "balancing invariant", "status": "covered", "notes": "Balancing scope, tolerance, per-currency balancing, control totals and imbalance handling at capture, posting and export are treated as first-class rather than assumed." }, { "dimension": "measurement and currency", "status": "covered", "notes": "Direction representation, exact decimal amounts, scale and rounding, zero and negative postings, multi-currency translation with rate provenance, and measurement basis under the applicable framework are all addressed." }, { "dimension": "tax and statutory reporting", "status": "covered", "notes": "Line-level tax codes, taxable base, tax amount, non-deductible portion and tax point date are modelled, with mapping to statutory account and tax categories; specific national profile obligations are out of scope." }, { "dimension": "security and integrity", "status": "covered", "notes": "Non-rewriteable storage or audit-trail alternative, content digests, before-and-after preservation, evidence link integrity and posting-actor anomaly detection are covered; cryptographic key management and platform hardening are not." }, { "dimension": "evidence and audit quality", "status": "covered", "notes": "Supporting document attachment and sufficiency, estimate flagging, risk indicators covering unusual accounts, unusual posters, period-end timing and weak narratives, and selection reporting are all modelled." }, { "dimension": "privacy", "status": "gap", "notes": "Personal data inside narratives, counterparty fields and attachments is identified and an erasure-versus-retention conflict question is posed, but no data protection instrument was read as a primary source in this pass. The privacy treatment is therefore structural only and must be completed against the applicable regime before use." }, { "dimension": "spatial", "status": "not-applicable", "notes": "Postings have jurisdiction and business unit context, which are modelled, but no geometry or physical location is intrinsic to a journal entry; place of supply for tax purposes belongs to the tax obligation model." } ], "known_omissions": [ "No data protection instrument (for example GDPR or an equivalent national regime) was read as a primary source, so the privacy finding is structural rather than legally grounded.", "ISO 21378:2019 and ISO/IEC 15944-4:2015 are paywalled; only their catalogue scope statements were consulted, so no field-level or ontology-level claim rests on them.", "The OECD SAF-T v2.0 guidance and the CPMI-IOSCO PFMI were retrieved as PDFs whose text layers were not machine-extractable; structural claims attributed to SAF-T are corroborated by the AICPA General Ledger Standard, the XBRL Global Ledger framework and the Norwegian national SAF-T profile, and the PFMI citation is limited to existence, date and subject matter.", "Non-IFRS national GAAP recognition and measurement differences, and Islamic finance and public-sector accrual variants, are not modelled beyond the generic framework reference on the ledger profile.", "Distributed-ledger and token postings are treated as a storage projection only; on-chain finality, forks, reorganisations and their effect on the immutability point are not modelled.", "Consolidation, intercompany elimination and multi-entity matching postings are referenced as an entry classification but not modelled as their own structure.", "Amount encryption, tokenisation and confidential-computing patterns for restricted ledgers are out of scope.", "Automated posting-rule authoring, testing and change control is referenced as a rule version but its own governance is not modelled.", "Official OECD SAF-T 2.0 XML schema was not retrieved in this run; TAF alignment is taken from XBRL GL's stated OECD tax-audit input, not from a national SAF-T implementation.", "ISO 20022 camt.053 XSD field inventory was not downloaded; cash-entry alignment uses the MDR, catalogue and bank-transaction-code documents.", "AAOIFI Islamic accounting, IPSAS public-sector budget accounting and Chinese Accounting Standards posting rules are not modelled.", "Distributed-ledger, hash-chained or token-settlement journals lack primary support here and are gaps.", "Payroll statutory postings, lease IFRS 16 mechanics, IFRS 9 expected-credit-loss engines and IFRS 15 contract-asset engines are consumers that generate journals, not part of this atomic posting model.", "UETR and LEI are correlation or party identifiers only; party and payment masters remain sibling models." ], "conflicts": [ "Direction is represented as an explicit debit/credit indicator in ledger taxonomy and statement message conventions, but as a signed amount in several practical extracts; the model declares the indicator plus non-negative magnitude authoritative and treats signed forms as derived, which will not round-trip losslessly from a signed-only source.", "Immutability of posted entries conflicts with erasure and minimisation duties over personal data carried in narratives and counterparty fields; the model resolves this by recorded decision rather than by asserting either duty prevails, and flags it as unresolved.", "Retention durations differ materially by regime - six years for broker-dealer ledgers and journals under the US rule cited, three years for private and six for public companies under the UK statute cited, with tax regimes differing again; no universal period exists and the model requires a per-jurisdiction declaration.", "Correction convention differs between reversing entries, storno that removes the original turnover, and negative postings; each produces different account turnover figures, so cross-border comparison of gross debit and credit totals is unsafe without knowing which convention was used.", "The account servicer's statement entry and the account owner's journal entry describe the same transfer from two books with different identifiers, dates and status vocabularies; treating either as the other's identity is a common and material error.", "National tax audit file profiles both constrain and extend the base schema, so a file valid against one national profile may be invalid or semantically different against another; profile version must always be pinned per delivery.", "ISO 20022 bank-to-customer entries are single-sided booked cash movements; a double-entry journal is a balanced multi-account event. Mapping is reconciliation, not identity.", "FIBO BP uses transaction for securities and derivatives process flows; that is not a ledger journal.", "IFRS recognition date and measurement basis may differ from bank booking date and cash amount.", "XBRL GL debitCreditCode with unsigned amount conflicts with signed-amount ledgers; canonical form prefers the code plus unsigned amount.", "PCAOB notes that consolidating, combination and reclassification adjustments may not appear as formal general-ledger journal entries; those top-side items are in scope as exceptions, not as proof that every adjustment is a GL voucher.", "The IFRS Conceptual Framework is not itself a Standard and does not override a specific IFRS that conflicts with it." ], "regional_assumptions": [ "Retention and electronic recordkeeping duties are illustrated using a US securities rule and UK company law; both are cited as examples of the shape of the obligation, not as globally applicable durations.", "Fraud-focused journal entry testing characteristics are drawn from a US public company auditing standard; equivalent international auditing requirements exist but were not read in this pass.", "Recognition, derecognition and measurement are anchored on the IFRS Conceptual Framework; jurisdictions applying national GAAP will differ on recognition timing and measurement basis and must override the ledger profile accordingly.", "Tax attributes are modelled on the shape used by European tax audit files, which is VAT-centric; sales-tax, GST and withholding regimes carry different attribute sets.", "Settlement finality semantics assume a designated system with a rulebook defining the moment of irrevocability; bilateral and correspondent arrangements without such a rulebook require a different evidencing approach.", "The ISO 17442 Legal Entity Identifier is assumed available for institutional counterparties; it is not generally available for natural persons or small unincorporated counterparties, so a fallback identifier scheme must be declared.", "PCAOB AS 2201 and AS 2401 bind US issuer audits and are treated as highly informative controls for any Dimension, not as worldwide law.", "IFRS Conceptual Framework 2018 is the recognition vocabulary used here; US GAAP, IPSAS and national GAAPs may assign different elements or timing.", "XBRL GL USK module reflects Saxonic (US, UK, Australia, Canada and similar) journal-tagging needs and is optional.", "ISO 20022 cash-reporting adoption and bank-transaction-code use vary by payment community (for example CGI, CBPR+, HVPS+) and must be recorded per servicer.", "Retention periods are jurisdiction-specific and are not given a single number in this model." ], "adversarial_checks": [ "Tested whether 'financial transaction' could be collapsed into the payment model: rejected, because a payment is an instruction and value flow that may produce several postings in several books, and because a booked account-servicer entry is a different party's record with its own identifier and status vocabulary.", "Tested whether account balances belong here: rejected, because balances are derived state owned by the parent account model, and because audit and tax file structures keep chart of accounts and trial balance in separate sections from general ledger entries.", "Searched for a normative source mandating double-entry universally: none found. The balancing invariant is asserted as a per-ledger declared scope with an explicit tolerance rather than as a universal law, since single-entry and cash-basis books exist and statutory wording requires records sufficient to show and explain transactions rather than double entry as such.", "Tested whether posting date could serve as an identifier or ordering key: rejected. Entries share dates, are backdated under authority, and arrive out of order; the identity priority forbids date-based identity and the serial naming rule makes the issued sequence, not the filename date, the ordering key.", "Tested whether 'immutable after posting' survives real practice: partially rejected as an absolute. Metadata enrichment and reclassification do occur, so the model permits narrowly scoped metadata-only patches under a preserved audit trail while forbidding any change to amount, direction, account, currency, effective date or period.", "Tested whether claiming conformance to any cited standard was defensible: rejected. Two key standards were only readable at catalogue level and two others only as non-extractable PDFs, so all external standards are recorded as alignments with conflicts listed, and no conformance is asserted.", "Tested whether a purely inline finding could be justified for every finding lacking an artifact: each of the eleven inline-only rationales names the artifact that already carries the data or the sibling model that owns it, rather than asserting that no artifact exists.", "A payment instruction is not a journal entry; treating WM-ECO-009 as this model would duplicate the payment sibling and break balancing semantics.", "A bank statement Ntry can net many underlying customer transactions; assuming one Ntry equals one economic event is a false completeness claim.", "Posted in-place edit would destroy the audit trail required by PCAOB journal-entry testing; any design that updates posted amounts fails the immutability policy.", "Using posting date as the identifier collides restatements, multi-book copies and same-day batches.", "Excluding automated journal entries from fraud testing contradicts PCAOB staff guidance that override risk is not limited to manual entries.", "Claiming ISO 20022 or IFRS conformance for a Dimension instance is unwarranted unless the specific message version and recognition policy are evidenced." ] }, "researchAdjudication": { "providerMode": "dual-provider", "activeProviders": [ "claude", "grok" ], "waivedProviders": [], "providerPolicy": {}, "boundaryDecision": { "entry_kind": "aggregate", "status": "accepted", "rationale": "The two providers disagree (Claude: aggregate, Grok: event). Aggregate is retained because the defining constraint of the subject is an invariant that binds a header to two or more posting lines and cannot be evaluated on any single record: debits must equal credits within a declared scope. A flat event record cannot carry that consistency boundary, cannot express partial reversal, and cannot express the single-sided servicer booking that Grok itself distinguishes from a balanced journal. Grok's event framing is not discarded: it is preserved inside the base as distinct event-time roles (document, effective, posting, value, booking) separated from capture and ingestion time, so the posting remains time-stamped without becoming its own entry kind." }, "decisions": [ { "concept": "Base provider selection", "disposition": "Claude adopted as base", "rationale": "Not chosen on size. Claude states six boundary notes that each name the owning sibling model with source refs, nine out-of-scope items against Grok's seven, and an inline-only rationale on every artifact-less finding that names where the data already lives. Grok's boundaries are sound but thinner and its coverage checklist marks every dimension covered, which is a weaker self-assessment than Claude's declared privacy gap." }, { "concept": "Entry kind aggregate versus event", "disposition": "Aggregate retained; event semantics kept as time roles", "rationale": "The balancing invariant spans header and lines and defines a consistency boundary no single event record can carry. Grok's event reading is preserved as the distinct document, posting, value and booking event times separated from ingestion time, so nothing is lost by not promoting event to the entry kind." }, { "concept": "Top-side, consolidating and reclassification adjustments outside the general ledger", "disposition": "Accepted from Grok into lyr-lifecycle-state as fnd-top-side-adjustments", "rationale": "Materially missing and self-declared as an omission by the base, tier-1 PCAOB evidence in the source provider, and it fits an existing lifecycle layer. Narrowed on ingest to the top-side axis so it does not restate fnd-reversal-correction." }, { "concept": "Management override of controls and ICFR control activities", "disposition": "Accepted from Grok into lyr-authority-policy as fnd-control-activities-override", "rationale": "The base asks who may post and which duty combinations are prohibited but never asks whether a control was overridden or what override evidence exists, which is the core assertion of the fraud standard both providers cite as a primary source." }, { "concept": "Grok f-master-identifiers identifier ladder", "disposition": "Rejected as duplicative", "rationale": "The base fnd-entry-identifier already covers the issuing system of record, line addressing stable across export and re-import, external reference resolution and uniqueness scope, and its coverage checklist already states the identity priority and forbids dates as identifiers. Multi-book stability is covered by q-parallel-ledgers." }, { "concept": "Grok f-monetary-fx and the ISO 4217 minor-unit exponent", "disposition": "Rejected as a finding; ISO 4217 deferred as a source addition", "rationale": "Amount, direction, currency, scale, rounding, rate provenance and revaluation linkage are all carried by fnd-amount-and-direction and fnd-currency-translation. What Grok genuinely adds is a currency registry citation, which is a source-level gap in the base and is handled through deferred research rather than by duplicating two findings." }, { "concept": "Grok f-interchange-alignment standard mappings", "disposition": "Rejected as duplicative", "rationale": "The base fnd-exchange-profiles owns target profile and version, unmapped-field loss, asserted export scope, account code mapping and profile-conflict precedence, and already references the XBRL GL SRCD mapping module in its boundary notes. Grok's module inventory is instance detail inside that finding, not a second finding." }, { "concept": "Grok q-inquiry-of-processors audit inquiry procedure", "disposition": "Rejected on boundary", "rationale": "Inquiry of individuals involved in processing entries is an audit engagement procedure about people, not context carried by or about the posting. Admitting it would pull audit fieldwork into a ledger artifact model whose boundary already stops at entry-level risk attributes and completeness attestation." }, { "concept": "Grok f-period-lock-access", "disposition": "Rejected as a finding; its operative half accepted as fn-reject-closed-period", "rationale": "Period state, who may post into each state, default-deny access and personal data on lines are already split across fnd-period-and-cutoff and fnd-access-control in the base. Only the exception-grant operation was missing, so it enters as a function rather than as overlapping structure." }, { "concept": "Grok f-balancing-rule and the single-sided bank entry", "disposition": "Rejected as duplicative structure", "rationale": "Balancing scope, tolerance and imbalance handling are owned by fnd-balancing-invariant, and the single-sided servicer booking is already stated in the base boundary note against WM-ECO-009, in fnd-settlement-finality and in the base conflict list. The distinction is retained; a second balancing finding is not." }, { "concept": "Grok q-going-concern-basis", "disposition": "Rejected as out of scope", "rationale": "Whether the consuming financial statements are prepared on a going-concern basis is a property of the reporting model, which both providers place outside this boundary. Carrying it on a posting would make every entry assert a statement-level judgement it does not own." }, { "concept": "Privacy dimension status", "disposition": "Claude's declared gap retained over Grok's covered", "rationale": "Neither provider read a data protection instrument as a primary source. Grok's access checklist entry mentions privacy on personal-data lines but rests on auditing standards, so the honest status is the base's structural-only gap, and it becomes a publication hold." }, { "concept": "Spatial dimension status", "disposition": "Claude's not-applicable retained", "rationale": "A posting has jurisdiction and business-unit context, which both providers model, but no intrinsic geometry or physical location. Grok marking spatial covered on the strength of a books-jurisdiction question overstates it; place of supply belongs to the tax obligation model." }, { "concept": "Direction representation: indicator versus signed amount", "disposition": "Indicator plus unsigned magnitude authoritative; signed forms derived", "rationale": "Both providers reached the same canonical form independently from XBRL GL and ISO 20022 conventions, so this is a resolved convergence, not a conflict. The known lossiness when importing from a signed-only source is carried forward as a recorded conflict in the draft, not as a blocker." }, { "concept": "Service layers", "disposition": "Merged", "rationale": "Both providers place identical service concerns (identity priority, RFC 3339 timestamps with explicit offset, default-deny access, retention and legal hold, serial artifact naming) at compatible scopes, so a single merged service layer avoids two competing statements of the same rule." }, { "concept": "Standards conformance posture", "disposition": "Alignment only, no conformance claim", "rationale": "Both providers independently reached this through adversarial checking: two ISO standards were readable only at catalogue level for the base, and neither provider retrieved the OECD SAF-T or camt.053 schemas. Every external standard is recorded as an alignment with its conflicts listed." } ], "publicationHolds": [ "Source and live-version verification is outstanding: every accepted URL must be re-fetched and version-pinned, and the four base sources readable only at catalogue or metadata level (ISO 21378:2019 and ISO/IEC 15944-4:2015 paywalled; OECD SAF-T v2.0 guidance and the CPMI-IOSCO PFMI retrieved as non-extractable PDFs) must be labelled catalogue-level-only in the published draft, with no field-level claim resting on them.", "Multi-profile domain validation is outstanding: the merged structure has not been exercised against at least two national tax-audit file profiles, one ERP journal projection and one ISO 20022 camt statement projection, so profile-specific field loss, code-list conflicts and round-trip behaviour remain unmeasured.", "The privacy dimension is a declared gap in both providers: no data protection instrument was read as a primary source, so the personal-data and erasure-versus-retention treatment is structural only and must not be published as legal guidance.", "No conformance claim to XBRL GL, SAF-T, ISO 20022, ISO 4217, ISO 21378, ISO/IEC 15944-4, IFRS or PCAOB standards may appear in the published draft; all external standards are recorded as alignments with their conflicts listed.", "The entry-kind adjudication must be published with its rationale, including the fact that the two providers disagreed, so downstream Dimensions do not silently re-model the posting as a flat event record and lose the balancing consistency boundary.", "Retention durations in the base are illustrated from a US securities rule and UK company law only; the draft must state that no universal period exists and that a per-jurisdiction declaration is required before any operational use." ], "deferredResearch": [ "Top-side, consolidating, combination and reclassification adjustments that never become formal general-ledger vouchers: decide whether the newly added fnd-top-side-adjustments warrants its own structure in this model or an explicit hand-off to a consolidation model, and source it beyond PCAOB staff guidance.", "Read a data protection instrument (GDPR or an equivalent national regime) as a primary source and rebuild the personal-data, erasure and retention-conflict treatment on it rather than on structural inference.", "Add ISO 4217 as a cited source for currency code and minor-unit exponent governance; the base asserts scale and rounding rules without a currency registry citation, and only the non-base provider carried one.", "Add the FIBO Business Process homonym boundary note distinguishing a market-side securities or derivatives transaction from a ledger posting; only the non-base provider carried it and boundary notes cannot be merged through this plan.", "Obtain the ISO 21378:2019 and ISO/IEC 15944-4:2015 texts, the OECD SAF-T 2.0 XML schema and the camt.053 XSD field inventory so field-level and ontology-level claims can rest on primary text rather than corroboration.", "Distributed-ledger, hash-chained and token-settlement postings and their effect on the immutability point are unsupported in both providers and are currently treated as a storage projection only.", "Non-IFRS national GAAP, IPSAS public-sector accrual and AAOIFI Islamic accounting recognition and measurement differences, none of which either provider modelled beyond a generic framework reference on the ledger profile.", "Governance of automated posting-rule authoring, testing and change control: the base references a posting-rule version but does not model who owns, tests or retires the rule that derives lines from a source event." ] }, "statistics": { "sources": 24, "bundles": 6, "layers": 13, "findings": 28, "questions": 102, "artifacts": 21, "functions": 15 } }