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

Vấn đề

Một doanh nhân 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ừ phù hợp GoBD, và làm thế nào để làm cho chúng có thể truy vết?

Thực tiễn hiện nay trong khu vực KMU:

• Chứng từ giấy trong các thư mục - không điện tử, không thể xử lý bằng máy, không truy vết được ngược/tiến
• PDF trong các tài khoản Cloud - không phù hợp GoBD (không có tính bất biến, không thể xử lý 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 chứng cứ
• Hóa đơn điện tử (XML) không được hiểu đúng - nhiều doanh nhân không biết rằng kể 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ừ được xếp theo ngày, 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, người kiểm tra không thể phân giải về chứng từ vì thiếu tham chiếu
• (Thường) Không có khả năng truy vết tiến - từ chứng từ không thể phân giải tới bút toán vì thiếu tham chiếu chéo

Luận điểm cốt lõi

Lưu trữ chứng từ phù hợp GoBD có nghĩa là:

1. Mỗi chứng từ có một định danh duy nhất (DocID) - uuidV7 (Object ID) chỉ riêng nó đã 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ừ còn nhận một hash SHA-256 làm kiểm tra tính 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ải cho bản thân định danh.
2. Mỗi chứng từ có một Sidecar - .v7g.md với phân loại (V7GUID), định danh đối tượng (uuidV7), Taxonomie, trạng thái Obsoleszenz, thời gian 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 mục nhật ký → chứng từ
4. Khả năng truy vết ngược - từ bút toán → chứng từ → mục nhật ký → uuidV7 phân giải được
5. Khả năng truy vết tiến - từ chứng từ → bút toán → sổ nhật ký → bảng cân đối mở đầu phân giải được
6. Hóa đơn điện tử: XML là tài liệu gốc - chứ không phải PDF (kể từ 2025, § 14 UStG, EN 16931)

Compliance by Design: Trật tự chứng từ không hình thành nhờ việc sắp xếp về sau, mà nhờ các trường bắt buộc về cấu trúc (SHA-256, V7GUID, Sidecar) và các Pre-Commit-Hook 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ử kể từ 2025: Kể từ ngày 1 tháng 1 năm 2025, hóa đơn điện tử là bắt buộc đối với các 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 ở một đị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.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) - chỉ riêng nó đã là định danh 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 chứng từ từ .gitcover Registry (loại chứng từ, tổ chức lưu trữ, truy vấn DB khi 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ổ nhật ký/Journal (khả năng truy vết tiến)
• 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
• Không có trường datetime riêng - thời gian nằm trong uuidV7

Khả năng truy vết ngược và tiến

Cơ sở GoBD: Khả năng truy vết ngược tương ứng với GoBD Rz. 146 (khả năng truy cứu - "bên thứ ba có chuyên môn trong thời gian hợp lý"). Khả năng truy vết tiến tương ứng với GoBD Rz. 147 (khả năng kiểm chứng). Cả hai đều được đảm bảo by Design thông qua SHA-256 + V7GUID + Sidecar - chứ không phải thông qua 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 vs. ZUGFeRD

Quan trọng - ZUGFeRD kể từ 2025: Khi có sai khác giữa phần XML và phần hình ảnh PDF, kể từ 2025 phần có cấu trúc (XML) có giá trị quyết định (BMF FAQ câu hỏi 12a). Hình ảnh PDF không còn là phần chi phối. 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 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 nhân 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ừ 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 cứu, 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ừ kế toán, § 147 Abs. 2 - có thể xử lý 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)
• 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 ý: Sự phân bổ này của các nguồn, Mirror và Community-Hub phản ánh hiện trạng hiện tại 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 hiện tại.