ED06 - Chứng từ, DMS, hóa đơn điện tử: Trật tự, truy vết ngược/xuôi

Vấn đề

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

Thực tế hiện nay trong lĩnh vực doanh nghiệp vừa và nhỏ:

• Chứng từ giấy trong bìa hồ sơ - không phải điện tử, không thể đánh giá bằng máy, không thể truy vết ngược/xuôi
• PDF trong tài khoản đám mây - không tuân thủ GoBD (không có tính bất biến, không có khả năng đánh giá bằng máy, phụ thuộc vào nhà cung cấp dịch vụ)
• Email có tệp đính kèm PDF - không được lưu trữ (hộp thư email không phải là kho lưu trữ), không có tính xác thực của chứng từ, không có chuỗi bằng chứng
• Hóa đơn điện tử (XML) không được hiểu đúng - 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 xuyên) Không có trật tự - chứng từ được xếp theo ngày, không theo quy trình; các bút toán không có tham chiếu chứng từ
• (Thường xuyên) Không có khả năng truy vết ngược - từ bút toán, người kiểm tra không thể phân giải đến chứng từ, vì thiếu tham chiếu
• (Thường xuyên) Không có khả năng truy vết xuôi - từ chứng từ không thể phân giải đến bút toán, vì thiếu các 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 là:

1. Mỗi chứng từ có một danh tính duy nhất (DocID) - uuidV7 (Object ID) đã tự nó là danh tính duy nhất của chứng từ, không phụ thuộc vào tên tệp. Ngoài ra, mỗi chứng từ nhận một mã băm SHA-256 như kiểm tra tính toàn vẹn bằng 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ụ với EF Core trong một Vertical App) - không phải bản thân danh tính.
2. Mỗi chứng từ có một Sidecar - .gc.md với phân loại (V7GUID), danh tính đối tượng (uuidV7), taxonomy, trạng thái lỗi thời, thời điểm ghi nhận (trong uuidV7 dưới dạng dấu thời gian 48-bit). Ngoại lệ (từ 261011): chứng từ được đưa vào một quy trình ký (chứng từ tự lập kỹ thuật số, ví dụ chứng từ chiêu đãi), mang siêu dữ liệu Sidecar của chúng hoàn toàn trong *.gcsig.md (khối source tích hợp, schema gcsig-1.4); một .gc.md riêng bị bỏ — không có các Sidecar cạnh tranh.
3. Mỗi bút toán tham chiếu chứng từ của nó - source_sha256 trong mục nhật ký → chứng từ
4. Truy vết ngược - từ bút toán → chứng từ → mục nhật ký → uuidV7 có thể phân giải
5. Truy vết xuôi - từ chứng từ → bút toán → sổ cái → bảng cân đối mở đầu có thể phân giải
6. Hóa đơn điện tử: 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 hình thành qua việc sắp xếp về sau, mà qua các trường bắt buộc mang tính cấu trúc (SHA-256, V7GUID, Sidecar) và Pre-Commit-Hooks, kiểm tra mọi bút toán về tham chiếu chứng từ.

Các loại chứng từ và đặc điểm GoBD của chúng

Quan trọng - Hóa đơn điện tử từ 2025: Từ ngày 1 tháng 1 năm 2025, hóa đơn điện tử là bắt buộc đối với giao dịch B2B giữa các doanh nghiệp trong nước (§ 14 UStG). Một PDF đơn giản không còn là hóa đơn điện tử - nó là "hóa đơn khác". Hóa đơn điện tử chỉ tồn tại khi được phát hành, truyền và nhận ở định dạng điện tử có cấu trúc (XML, EN 16931). Xem ED01 "Hóa đơn điện tử: Các đị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.gc.md  # Sidecar
│   │   └── rechnung_002.pdf      # Sonstige Rechnung (PDF)
│   │   └── rechnung_002.pdf.gc.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 cho mỗi chứng từ (bắt buộc)

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

{
  "$schema": "https://gitcover.org/schemas/v7g-sidecar-2.0.schema.json",
  "V7GUID": "<V7GUID-Class-aus-Registry>",
  "docUid": "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) - đã tự nó là danh tính duy nhất (DocID) của chứng từ, được tạo với dấu thời gian định trước, dấu thời gian 48-bit được 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/nhật ký (truy vết xuôi)
• 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ừ chỉ là uuidV7
• Không có trường datetime riêng - thời gian nằm trong uuidV7

Truy vết ngược và xuôi

Liên quan GoBD: Truy vết ngược tương ứng GoBD Rz. 146 (khả năng truy vết - "một bên thứ ba có chuyên môn trong thời gian hợp lý"). Truy vết xuôi tương ứng GoBD Rz. 147 (khả năng kiểm tra). Cả hai được bảo đảm by Design qua SHA-256 + V7GUID + Sidecar - không qua các tham chiếu chéo thủ công.

Khả năng tìm thấy: docUid thay vì tên/đường dẫn (261026)

Mỗi tham chiếu chứng từ trong một hóa đơn mang docUid của chứng từ gốc, không phải tên hoặc đường dẫn: trong XML là cac:AdditionalDocumentReference/cbc:ID (uuidV7), trong Sidecar/GCPN là docUid. Registry DMS tiếp nhận cùng docUid đó làm object_id - nó không tạo ra danh tính thứ hai. Nhờ đó, một chứng từ có thể được tìm thấy duy nhất qua docUid, ngay cả khi nó được đổi tên hoặc di chuyển.

Action tạo hoặc lưu một chứng từ được quản lý dưới dạng pgid (Process-Gateway, lớp V7GUID): produced_by_pgid cho việc tạo (ví dụ tạo hóa đơn 180), stored_by_pgid cho việc đăng ký DMS (ví dụ 183). Danh mục: GCUV/TOP/compliance/process_gateways.json; giá trị 8-bit chuẩn: OSS/TOP/.gitcover/dictionaries/gateway_ids.json.

GCPN một tệp: Với mỗi hóa đơn có một .gcpn.md, dẫn XML (tài liệu gốc) và PDF (chế độ xem) trong documents[], chứa workflow create→pdf→present→accept→sign→register cũng như events và relations (hợp đồng/chứng từ chi phí). XML/PDF vẫn là các tệp riêng biệt; một .gc.md riêng bị bỏ. Truy vết xuôi (Rz. 147) người ta đọc từ GCPN đến các tài liệu, truy vết ngược (Rz. 146) từ docUid trong DMS qua GCPN đến các chứng từ.

Quy tắc promote: Sau khi quét repo và tạo Sidecar, một .gc.md có thể được làm giàu vào GCPN; dữ liệu JSON Sidecar được nhúng (GCPN = tập cha, .gc.md = tập con). Sau đó, .gc.md riêng là dư thừa và có thể bị xóa; lịch sử Git vẫn là bằng chứng GoBD, GCPN là SSoT.

Danh tính hóa đơn: invoice_id là một uuidV7 (tiêu chí trật tự/tham chiếu); invoice_no chỉ là văn bản. Seller/Buyer được tham chiếu qua Party-uuidV7 của họ (creditor/vendor hoặc debitor/customer), không qua tên thật (PII).

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

XRechnung so với ZUGFeRD

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

Pre-Commit-Hook cho hóa đơn điện tử

Pre-Commit-Hook kiểm tra ở hóa đơn điện tử:

Lưu trữ email

Email là thư thương mại hoặc thư kinh doanh theo nghĩa của § 147 Abs. 1 Nr. 2/3 AO và do đó phải được lưu giữ 6 năm. Nhiều doanh nhân không lưu trữ email - đó là vi phạm GoBD.

Mẹo thực hành: Một Git-Repo có thể lưu trữ email (EML/MBOX) và tệp đính kèm (PDF, XML) song song - với sự phân tách rõ ràng theo loại chứng từ trong Sidecar (v7g_taxonomy). Pre-Commit-Hook kiểm tra rằng mỗi EML có một Sidecar và mỗi tệp đính kèm được phân loại riêng.

Tính đầy đủ của chứng từ (Pre-Commit-Hook)

Đòn bẩy rủi ro

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

Có thể suy ra từ ED06:

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

Nguồn

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

Cấu trúc nguồn và liên kết tham chiếu CDN

Lưu ý: Việc phân loại 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 chuẩn tương ứng trên gitcover.org để biết trạng thái hiện tại.