ED05 - Chứng từ, DMS, e-Hóa đơn: Trật tự, Truy vết Retrograde/Progressive

Vấn đề

Một doanh nhân bắt đầu lưu trữ chứng từ - và đối mặt với câu hỏi: Tôi sắp xếp chứng từ tuân thủ GoBD thế nào, và làm cho chúng truy vết được ra sao?

Thực hành hiện nay trong lĩnh vực SME:

• Chứng từ giấy trong bìa - không điện tử, không đánh giá bằng máy, không truy vết retrograde/progressive
• PDF trong tài khoản đám mây - không tuân thủ GoBD (không không thay đổi, không đánh giá bằng máy, phụ thuộc nhà cung cấp)
• E-mail với tệp đính kèm PDF - không lưu trữ (hộp thư e-mail không phải archive), không xác thực chứng từ, không chuỗi bằng chứng
• e-hóa đơn (XML) không hiểu - nhiều doanh nhân không biết rằng từ 2025 tệp XML là tài liệu gốc, không phải PDF
• (Thường) Không trật tự - chứng từ lưu theo ngày, không theo vụ; booking không có tham chiếu chứng từ
• (Thường) Không truy vết retrograde - từ booking kiểm toán viên không giải được đến chứng từ vì thiếu tham chiếu
• (Thường) Không truy vết progressive - từ chứng từ không giải được đến booking vì thiếu tham chiếu chéo

Tuyên bố cốt lõi

Lưu trữ chứng từ tuân thủ GoBD có nghĩa:

1. Mỗi chứng từ có danh tính duy nhất (DocID) - uuidV7 (Object ID) đã một mình là danh tính duy nhất của chứng từ, độc lập tên tệp. Thêm mỗi chứng từ nhận hash SHA-256 làm kiểm tra toàn vẹn mật mã. Composite Key V7GUID:uuidV7 phục vụ tổ chức lưu trữ (ví dụ theo loại chứng từ) và truy vấn DB (ví dụ EF Core trong Vertical App) - không phải bản thân danh tính.
2. Mỗi chứng từ có sidecar - .v7g.md với phân loại (V7GUID), danh tính đối tượng (uuidV7), taxonomy, trạng thái obsolescence, thời điểm ghi nhận (trong uuidV7 dạng timestamp 48-bit)
3. Mỗi booking tham chiếu chứng từ - source_sha256 trong mục nhật ký → chứng từ
4. Truy vết retrograde - giải quyết từ booking → chứng từ → mục nhật ký → uuidV7
5. Truy vết progressive - giải quyết từ chứng từ → booking → sổ cái → bảng cân đối đầu kỳ
6. e-hóa đơn: XML là tài liệu gốc - không phải PDF (từ 2025, § 14 UStG, EN 16931)

Compliance by Design: Trật tự chứng từ không phát sinh qua sắp xếp sau, mà qua trường bắt buộc mang tính cấu trúc (SHA-256, V7GUID, sidecar) và Pre-Commit hook kiểm tra mỗi booking có tham chiếu chứng từ.

Loại chứng từ và đặc thù GoBD

Quan trọng - e-hóa đơn từ 2025: Từ 1.1.2025 e-hóa đơn bắt buộc cho doanh thu B2B giữa doanh nghiệp trong nước (§ 14 UStG). Một PDF đơn giản không còn là e-hóa đơn - nó là "hóa đơn khác". E-hóa đơn chỉ tồn tại nếu được xuất, truyền và nhận trong định dạng điện tử có cấu trúc (XML, EN 16931). Xem ED01 "e-hóa đơn: định dạng XML là tài liệu gốc trong AO".

Phân loại chứng từ trong Git Repo

Cấu trúc thư mục

ORG-1/sources/                    # Belegarchiv (Tenant: ORG-1)
├── eingangsrechnungen/           # Eingangsrechnungen (Lieferanten)
│   ├── 260815/                   # Nach Datum (YYMMDD)
│   │   ├── rechnung_001.xml      # E-Rechnung (XRechnung)
│   │   ├── rechnung_001.xml.v7g.md  # Sidecar
│   │   └── rechnung_002.pdf      # Sonstige Rechnung (PDF)
│   │   └── rechnung_002.pdf.v7g.md  # Sidecar
├── ausgangsrechnungen/           # Ausgangsrechnungen (Kunden)
├── lohnbelege/                   # Lohnabrechnungen
├── sv-bescheide/                 # SV-Bescheide, VBG-Bescheide
├── vertraege/                    # Verträge (periodenübergreifend)
├── korrespondenz/                # E-Mails, Briefe
└── sonstige/                     # Sonstige Belege

Sidecar mỗi chứng từ (bắt buộc)

Mỗi chứng từ nhận một sidecar .v7g.md với Composite Key V7GUID:uuidV7:

{
  "$schema": "https://gitcover.org/schemas/v7g-sidecar-1.0.schema.json",
  "V7GUID": "<V7GUID-Class-aus-Registry>",
  "uuidV7": "019f2c6f-0900-7001-8000-000000000001",
  "sha256": "ab94670c0dd8499c27ef2feddd1d9c5925977d55a52150a6fca0f6567d2e5e79",
  "title": "260815_Rechnung_001.xml",
  "original_filename": "Rechnung_001.xml",
  "locations": [
    {
      "unc_path": "./ORG-1/sources/eingangsrechnungen/260815/rechnung_001.xml",
      "from": "260815",
      "to": null,
      "note": "Primärspeicherort"
    }
  ],
  "v7g_taxonomy": [
    {
      "v7guid": "019f2c6f-0900-7000-8000-000000000000",
      "taxonomy": "ORG-1/Eingangsrechnung",
      "valid_from": "260815",
      "valid_to": null,
      "note": "Tenant: ORG-1, Category: Eingangsrechnung, Sphäre: wirtschaftlich"
    }
  ],
  "gcpn": {
    "prima_nota_ref": "GB-2026-08-001",
    "journal_entry_ref": "J-2026-08-001"
  },
  "obsolescence": {
    "status": "active",
    "superseded_by": null,
    "superseded_at": null
  }
}

Composite Key V7GUID:uuidV7 - tổ chức lưu trữ và truy vấn:

• uuidV7 (Object ID) - đã một mình là danh tính duy nhất (DocID) của chứng từ, tạo với timestamp định sẵn, timestamp 48-bit neo trong GUID
• V7GUID (Class) - phân loại loại chứng từ từ registry .gitcover (loại chứng từ, tổ chức lưu trữ, truy vấn DB trong Vertical App với EF Core)
• v7g_taxonomy[].v7guid - Object ID của chứng từ được phân loại
• gcpn.prima_nota_ref / journal_entry_ref - tham chiếu chéo đến sổ cái/journal (truy vết progressive)
• Composite Key V7GUID:uuidV7 phục vụ tổ chức lưu trữ và truy vấn - danh tính của chứng từ là uuidV7 một mình
• Không có trường datetime riêng - thời gian nằm trong uuidV7

Truy vết Retrograde và Progressive

Tham chiếu GoBD: Truy vết retrograde tương ứng GoBD Rz. 146 (truy vết - "bên thứ ba có hiểu biết trong thời gian hợp lý"). Truy vết progressive tương ứng GoBD Rz. 147 (kiểm toán). Cả hai được đảm bảo by Design qua SHA-256 + V7GUID + sidecar - không qua tham chiếu chéo thủ công.

e-Hóa đơn: XML là tài liệu gốc

XRechnung vs. ZUGFeRD

Quan trọng - ZUGFeRD từ 2025: Khi có sai lệch giữa phần XML và phần hình PDF, phần có cấu trúc (XML) có thẩm quyền từ 2025 (BMF FAQ câu 12a). Hình PDF không còn dẫn đầu. Sidecar phải tham chiếu XML làm tài liệu gốc, không phải PDF.

Pre-Commit Hook cho e-hóa đơn

Pre-Commit hook kiểm tra cho e-hóa đơn:

Lưu trữ E-mail

E-mail là thương thư hoặc thư kinh doanh theo § 147 Abs. 1 Nr. 2/3 AO và do đó phải lưu 6 năm. Nhiều doanh nhân không lưu e-mail - đây là vi phạm GoBD.

Mẹo thực tế: Một Git repo có thể lưu e-mail (EML) và đính kèm (PDF, XML) song song - với tách biệt rõ theo loại chứng từ trong sidecar (v7g_taxonomy). Pre-Commit hook kiểm tra mỗi EML có sidecar và mỗi đính kèm được phân loại riêng.

Đầy đủ chứng từ (Pre-Commit Hook)

Đòn bẩy rủi ro

Yêu cầu Harness (Xem trước)

Dẫn xuất từ ED05:

Danh sách yêu cầu đầy đủ trong Harness-Anforderungen.md.

Nguồn

• GoBD (thư BMF, Rz. 146 - truy vết, Rz. 147 - kiểm toán)
• AO (§ 147 Abs. 1 Nr. 2/3 - thương thư, § 147 Abs. 1 Nr. 4 - chứng từ booking, § 147 Abs. 2 - đánh giá bằng máy, § 147 Abs. 3 - thời hạn lưu trữ)
• UStG (§ 14 - e-hóa đơn, § 14b - lưu trữ)
• BMF FAQ về e-hóa đơn (tháng 3/2026)
• EN 16931 (CEN/TC 434 - XRechnung, ZUGFeRD)
• AFJD/agents/ (ẩn danh) - khái niệm SSoT với archive chứng từ, sidecar

Topo nguồn và liên kết tham chiếu CDN

Lưu ý: Phân công nguồn, mirror và community hub này phản ánh trạng thái hiện tại và có thể thay đổi. Vui lòng kiểm tra nguồn chính thức tương ứng trên gitcover.org cho trạng thái hiện tại.