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

Vấn đề

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

Thực tiễn hiện nay trong lĩnh vực doanh nghiệp vừa và nhỏ (KMU):

• Chứng từ giấy trong các thư mục - không điện tử, không thể đánh giá bằng máy, không truy vết được ngược/xuôi
• PDF trong tài khoản Cloud - không tuân thủ GoBD (không có tính bất biến, không thể đánh giá bằng máy, phụ thuộc vào nhà cung cấp dịch vụ)
• Email có tệp PDF đính kèm - 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) chưa được hiểu đúng - nhiều doanh nghiệp không biết rằng từ năm 2025, tệp XML mới là tài liệu gốc, chứ không phải PDF
• (Thường) Không có trật tự - chứng từ xếp theo ngày tháng, không theo nghiệp vụ; bút toán không có tham chiếu chứng từ
• (Thường) Không có khả năng truy vết ngược - từ bút toán, kiểm toán viên không thể truy ngược về chứng từ vì thiếu tham chiếu
• (Thường) Không có khả năng truy vết xuôi - từ chứng từ không thể truy tới bút toán vì thiếu tham chiếu chéo

Thông điệp 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 định danh duy nhất (DocID) - uuidV7 (Object ID) một mình đã là định danh duy nhất của chứng từ, độc lập với tên tệp. Ngoài ra, mỗi chứng từ nhận một giá trị băm SHA-256 làm kiểm tra toàn vẹn bằng mật mã. Composite Key V7GUID:uuidV7 phục vụ cho 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) - chứ không phục vụ cho bản thân định danh.
2. Mỗi chứng từ có một Sidecar - .v7g.md chứa phân loại (V7GUID), định danh đối tượng (uuidV7), taxonomy, trạng thái lỗi thời (obsolescence), thời điểm ghi nhận (trong uuidV7 dưới dạng dấu thời gian 48 bit)
3. Mỗi bút toán tham chiếu chứng từ của nó - source_sha256 trong bản ghi nhật ký → chứng từ
4. Khả năng truy vết ngược - từ bút toán → chứng từ → bản ghi nhật ký → uuidV7 đều truy được
5. Khả năng truy vết xuôi - từ chứng từ → bút toán → sổ cái → bảng cân đối mở đầu đều truy được
6. Hóa đơn điện tử: XML là tài liệu gốc - chứ 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 từ việc sắp xếp sau này, mà từ các trường bắt buộc mang tính cấu trúc (SHA-256, V7GUID, Sidecar) và các Pre-Commit-Hook kiểm tra tham chiếu chứng từ của mỗi bút toán.

Các loại chứng từ và đặc thù 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 tệp PDF đơn thuần không còn là hóa đơn điện tử - nó là một "hóa đơn khác". Hóa đơn điện tử chỉ được coi là tồn tại khi nó được lập, 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ử: Định dạng XML là tài liệu gốc theo 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 cho 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à định danh duy nhất (DocID) của chứng từ, được tạo với dấu thời gian định sẵn, dấu thời gian 48 bit được neo trong GUID
• V7GUID (Class) - phân loại loại chứng từ từ .gitcover Registry (loại chứng từ, tổ chức lưu trữ, truy vấn DB khi dùng 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 tới sổ cái/nhật ký (khả năng truy vết xuôi)
• Composite Key V7GUID:uuidV7 phục vụ cho tổ chức lưu trữ và truy vấn - định danh của chứng từ chỉ là uuidV7 một mình
• Không có trường datetime riêng - thời gian nằm trong uuidV7

Khả năng truy vết ngược và xuôi

Liên hệ GoBD: Khả năng truy vết ngược tương ứng với GoBD Rz. 146 (Nachvollziehbarkeit - "bên thứ ba có chuyên môn trong thời gian hợp lý"). Khả năng truy vết xuôi tương ứng với GoBD Rz. 147 (Nachprüfbarkeit). Cả hai đều được bảo đảm by Design nhờ SHA-256 + V7GUID + Sidecar - chứ không phải bằng các tham chiếu chéo thủ công.

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 khác giữa phần XML và phần hình PDF, từ 2025 phần có cấu trúc (XML) là phần quyết định (BMF FAQ câu hỏi 12a). Hình PDF không còn là phần dẫn chiếu chính. Sidecar phải tham chiếu XML là tài liệu gốc, chứ không phải PDF.

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

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

Lưu trữ email

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

Mẹo thực tế: Một Git-Repo có thể lưu trữ song song email (EML/MBOX) và tệp đính kèm (PDF, XML) - 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ừ ED05:

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

Nguồn

• GoBD (Công văn BMF, Rz. 146 - khả năng truy nguyên, Rz. 147 - khả năng kiểm chứng)
• AO (§ 147 Abs. 1 Nr. 2/3 - thư từ 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ử (cập nhật tháng 3/2026)
• EN 16931 (CEN/TC 434 - XRechnung, ZUGFeRD)
• AFJD/agents/ (ẩn danh) - khái niệm SSoT với kho lưu trữ chứng từ, Sidecar

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

Lưu ý: Cách phân vai này giữa nguồn, Mirror và Community-Hub phản ánh hiện trạng và có thể thay đổi. Vui lòng kiểm tra nguồn chính tắc tương ứng trên gitcover.org để biết trạng thái mới nhất.