Container data structure for UUIDv7-based, audit-proof business document management with dynamic predecessor / successor chaining (GitCover PrimaNota)

Abstract

Container data structure (.v7g.md) for audit-proof business document management, characterized by ◯ a YAML front matter section (10) with a time-ordered UUIDv7 identifier (11) according to RFC 9562, a document type (12), predecessor references (13) to predecessor documents, successor references (14) to successor documents and match key fields (15) for automatic chain association, ◯ a Markdown section (20) for human-readable metadata and descriptions, o embedded JSON code blocks (30) containing machine-processable business data, and ◯ a Git commit hash reference (40) for cryptographic integrity proof.

Description

1. Technical field

[0001] The invention relates to a data structure for the audit-proof management of business documents, in particular a container format that combines human-readable and machine-processable elements, uses time-ordered UUIDv7 identifiers according to RFC 9562 and enables dynamic predecessor / successor chaining with multi-key matching. 2. State of the art

[0002] Existing document management systems typically use proprietary data formats that are either purely machine-readable (XML, JSON) or purely human-readable (PDF, Word). GUIDs are often used as random identifiers (UUIDv4) without any temporal order. Chaining mechanisms such as blockchain, Merkle-DAG (IPFS), or RFC 5829 (predecessor-version / successor-version) do not support the retroactive insertion of predecessors into existing chains. DATEV BEDI uses static GUID links without dynamic chaining. While Git, as a version control system, offers SHA-256 hash chaining, it lacks native support for business process-related document relationships. UUIDv7 (RFC 9562, standardized May 2024) has not yet been used for GoBD-compliant document management. 3. Object of the invention

[0003] Provision of a data structure that enables time-ordered document identification with lexicographical sortability, combines human-readable and machine-processable formats in one container, supports the subsequent insertion of documents as predecessors into existing chains, provides automatic chain association through multi-key matching (order number, debtor / creditor, amount), ensures cryptographic integrity protection through Git integration, and enables GoBD-compliant progressive and retrospective auditability (para. 80). 4. Summary of the invention

[0004] The container data structure according to the invention (.v7g.md) comprises: a YAML front matter section (10) with UUIDv7 identifier (11), document type (12), predecessor references (13), successor references (14), match key fields (15), and compliance status (16); a Markdown section (20) for human-readable metadata and descriptions; embedded JSON code blocks (30) with structured business data (document data, journal entries); and a Git commit hash reference (40) for integrity verification. The data structure is persisted in a Git repository (50), with each change being logged as an immutable commit. 5. Brief description of the drawings

[0005] The drawings are executed in monochrome representation according to DPMA specifications on DIN A4 paper. The reference symbol corridor (10)-(70) is used consistently and is listed in the reference symbol list. Fig.1: Construction of the container data structure (.v7g.md) with YAML front matter, Markdown section and JSON artifacts. Fig. 2: Dynamic chain formation with subsequent predecessor insert. Fig. 3: Multi-key matching mechanism for automatic chain association. Fig. 4: Git repository integration with SHA-256 hash chaining. Fig. 5: Progressive and retrograde audit trails according to GoBD section 80. 6. Detailed description 6.1 Container structure

[0006] The data structure (1) consists of three main sections: The YAML front matter (10) begins with a separator line (---) and contains structured metadata. The UUIDv7 identifier (11) is generated according to RFC 9562 with a 48-bit Unix millisecond timestamp and a 74-bit random component, thus ensuring chronological order and lexicographical sortability. The document type (12) classifies the document (e.g., "business transaction", "receipt", "booking"). The predecessor references (13) refer to predecessor documents with a relation (e.g., "initiated_by"). The successor references (14) refer to successor documents with a relation (e.g., "billed_by"). The match key fields (15) contain business keys for automatic chain association: order number (po_number), debtor / creditor ID (debitor / creditor), gross amount (amount_gross). The compliance status (16) documents GoBD audit results.

[0007] The Markdown section (20) contains human-readable descriptions, tables and explanations of the business transaction.

[0008] The JSON code blocks (30) are embedded in Markdown code blocks and contain machine-processable business data: document data (31) with document number, amounts and hash; journal entries (32) with debit / credit accounts and input tax. 6.2 UUIDv7 Properties

[0009] The UUIDv7 identifier (11) according to RFC 9562 has the following properties relevant to the invention: Time ordering by means of a 48-bit millisecond timestamp enables chronological sorting; Collision avoidance by means of a 74-bit random component; Deterministic generation if required by hash-based variants; Lexicographic sortability as a UUID string; No database sequence is required for O(1) generation. 6.3 Dynamic chain formation

[0010] Predecessor / successor chaining (13, 14) enables dynamic chaining regardless of the capture order: A document captured later can insert itself as the predecessor of an earlier document. The multi-key matcher (60) identifies related documents by matching them on business keys. The chain manager (61) establishes bidirectional references and updates affected documents. Each chaining operation is logged as a Git commit (50). 6.4 Git Integration

[0011] The Git repository (50) serves as a persistence layer with the following properties: SHA-256 hash chaining (51) ensures integrity; Immutable commits (52) log every change; GPG signature (53) enables non-repudiation; Commit history (54) forms a complete audit trail; The Git commit hash reference (40) in the container links the document to the commit. 6.5 GoBD compliance

[0012] The data structure supports the requirements according to GoBD section 80: Progressive audit (70): Tracking document → posting → completion via successor chain; Retrograde audit (71): Tracking completion → posting → document via predecessor chain; Seamless documentation via Git commit history; Immutability via SHA-256 hash chaining. 7. Advantages of the invention

[0013] Time-ordered identification via UUIDv7 without central sequence generation. Human-machine hybrid format: readable for auditors, processable for systems. Dynamic chaining: subsequent predecessor insertion without chain break. Automatic chaining through multi-key matching reduces manual assignment. Cryptographic integrity through Git SHA-256 chaining. GoBD compliance through bidirectional audit trails. Open-source stack without vendor lock-in. On-premises and cloud compatibility. 8. Industrial Applicability

[0014] The data structure can be used in: GoBD-compliant accounting (§§ 146-147 AO); audit-proof document archiving; audit trail systems for compliance evidence; business process documentation in SMEs and administration; supply chain documentation with supplier / customer linking; tax consulting and auditing software. Reference symbol list Reference sign Designation figure Container level 1 Container data structure (.v7g.md) 1,2,3,4 1a Container invoice 2 1b Container order 2 1c Container delivery note 2 YAML Front Matter 10 YAML front matte section 1 11 UUIDv7 identifier 1 12 Document type 1 13 Predecessor references 1,2,5 14 Successor references 1,2,5 15 Match key fields 1,3 16 Compliance status 1 Markdown section 20 Markdown section 1 21 Description (human-readable) 1 22 tables 1 JSON code blocks 30 JSON code blocks 1 31 Document data 1 32 Booking entries 1 Git integration 40 Git commit hash reference 1, 4 Reference sign Designation figure 50 Git repository 4 51 SHA-256 hash chain 4 52 Immutable Commits 3,4 53 GPG signature 4 54 Commit History 4 55 Database index 3 56 Match Key Index 3 Chain formation 60 Multi-Key Matcher 3 61 Chain Manager 3 62 PO Number Match 3 63 Debtor / creditor match 3 64 Amount Match 3 65 Candidate ranking 3 66 Reference Update 3 GoBD audit 70 Progressive examination 5 71 Retrograde testing 5

Claims

[1] Container data structure (.v7g.md) for audit-proof business document management, characterized by ◯ a YAML front matter section (10) with a time-ordered UUIDv7 identifier (11) according to RFC 9562, a document type (12), predecessor references (13) to predecessor documents, successor references (14) to successor documents and match key fields (15) for automatic chain association, ◯ a Markdown section (20) for human-readable metadata and descriptions, o embedded JSON code blocks (30) containing machine-processable business data, and ◯ a Git commit hash reference (40) for cryptographic integrity proof. [2] Container data structure according to claim 1, characterized by , that the UUIDv7 identifier (11) includes a 48-bit Unix millisecond timestamp for temporal ordering and lexicographic sortability. [3] Container data structure according to claim 1, characterized by, that the predecessor references (13) and successor references (14) each contain a relation (e.g. “initiated_by”, “settled_by”) for the semantic typing of the chain. [4] Container data structure according to claim 1, characterized by , that the match key fields (15) include at least one of the following business keys: Order number (po_number), debtor / creditor identifier, gross amount (amount_gross). [5] Container data structure according to claim 1, characterized by , that the embedded JSON code blocks (30) include document data (31) with document number, amounts and SHA-256 hash of the original document, as well as journal entries (32) with debit / credit accounts. [6] Container data structure according to claim 1, characterized by , that the YAML front matter section (10) additionally contains a compliance status (16) with results of the progressive and retrograde audit according to GoBD para.

80. [7] Ensemble of container data structures according to claim 1, characterized by , that o several container data structures (1a, 1b, 1c) are linked to a document chain by predecessor references (13) and successor references (14), ◯ the chaining occurs independently of the capture order, so that a later captured document can be inserted as a predecessor of an earlier captured document, and ◯ the ensemble is stored in a Git repository (50) using SHA-256 hash chaining (51). [8] Ensemble according to claim 7, characterized by that the document chain reflects a complete business transaction from order to delivery note and invoice to payment. [9] Ensemble according to claim 7, characterized by , that each chaining operation is logged as an immutable Git commit (52) with a timestamp and optional GPG signature (53). [10] Ensemble according to claim 7, characterized by, that the document chain enables bidirectional traversal for progressive auditing (70) and retrograde auditing (71) in accordance with GoBD para.

80. [11] Storage arrangement for container data structures according to claim 1, characterized by , that o the container data structures (1) in a Git repository (50) are stored as files in the file system, ◯ a database index (55) indexes the match key fields (15) and UUIDv7 identifiers (11) for fast queries, and ◯ the Multi-Key-Matcher (60) automatically determines chain associations by comparing the Match-Key fields when new documents are received. [12] Storage arrangement according to claim 11, characterized by , that the chain manager (61) updates bidirectional references in all affected container data structures when a chain association is found and persists the changes atomically as a Git commit (52). [13] Storage arrangement according to claim 11, characterized bythat the storage arrangement supports on-premise operation without cloud dependency and is based entirely on open-source components. [14] Storage arrangement according to claim 11, characterized by that the storage arrangement supports an air-gapped mode with subsequent signature-based synchronization between isolated instances.

Images