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

Vấn đề

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

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

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

Kernaussage

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) đã là duy nhất định danh 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 được hash SHA-256 để kiểm tra toàn vẹn bằng mật mã. Khóa tổ hợp V7GUID:uuidV7 dùng để tổ chức lưu trữ (ví dụ theo loại chứng từ) và truy vấn cơ sở dữ liệu (ví dụ khi dùng EF Core trong Vertical App) - không phải 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), 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 số, ví dụ chứng từ chi phí tiếp khách) mang toàn bộ siêu dữ liệu Sidecar trong *.gcsig.md (khối source tích hợp, lược đồ gcsig-1.4); không có .v7g.md riêng — không có Sidecar cạnh tranh.
3. Mỗi bút toán tham chiếu chứng từ của nó - source_sha256 trong bản ghi sổ nhật ký → Chứng từ
4. Khả năng truy vết ngược - có thể tra cứu từ bút toán → chứng từ → bản ghi sổ nhật ký → uuidV7
5. Khả năng truy vết tiến - có thể tra cứu từ chứng từ → bút toán → sổ cái → bảng cân đối khai mở đầu
6. Hóa đơn điện tử: XML là tài liệu gốc - không phải PDF (từ năm 2025, § 14 UStG, EN 16931)

Tuân thủ theo thiết kế: Trật tự chứng từ không được tạo ra bằng việc sắp xếp bổ sung sau, mà bằng các trường bắt buộc có cấu trúc (SHA-256, V7GUID, Sidecar) và các Pre-Commit-Hook kiểm tra từng bút toán về tham chiếu chứng từ.

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ừ năm 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 giản không còn là hóa đơn điện tử - đó là một "hóa đơn khác". Chỉ khi hóa đơn điện tử được phát hành, truyền tải và nhận trong một định dạng điện tử có cấu trúc (XML, EN 16931) thì đó mới là hóa đơn điện tử. 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 kho Git

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 khóa tổ hợp V7GUID:uuidV7:

{
  "$schema": "https://gitcover.org/schemas/v7g-sidecar-1.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
  }
}

Khóa tổ hợp V7GUID:uuidV7 - Tổ chức lưu trữ và truy vấn:

• uuidV7 (Object ID) - đã là duy nhất định danh (DocID) của chứng từ, được tạo với mốc thời gian xác định trước, dấu thời gian 48 bit được ghi trong GUID
• V7GUID (Class) - phân loại loại chứng từ theo registry .gitcover (loại chứng từ, tổ chức lưu trữ, truy vấn cơ sở dữ liệu khi dùng Vertical App với EF Core)
• v7g_taxonomy[].v7guid - Object ID của chứng từ đã phân loại
• gcpn.prima_nota_ref / journal_entry_ref - tham chiếu chéo đến sổ cái/sổ nhật ký (khả năng truy vết tiến)
• Khóa tổ hợp V7GUID:uuidV7 dùng để tổ chức lưu trữ và truy vấn - định danh 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

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

Liên quan GoBD: Khả năng truy vết ngược tương ứng với GoBD Rz. 146 (Khả năng truy vết - "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 được đảm bảo theo thiết kế bằng SHA-256 + V7GUID + Sidecar - không phải bằng 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ừ năm 2025: Khi có khác biệt giữa phần XML và phần ảnh PDF, từ năm 2025 phần có cấu trúc (XML-) là phần quyết định (BMF FAQ Frage 12a). Ảnh PDF không còn dẫn dắt. Sidecar phải tham chiếu XML với tư cách 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 với hóa đơn điện tử:

Lưu trữ E-mail

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

Mẹo thực tiễn: Một kho Git có thể lưu trữ song song E-mail (EML/MBOX) và tệp đính kèm (PDF, XML) - với việc 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 đều có 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 đủ tại Harness-Anforderungen.md.

Nguồn

• GoBD (văn bản BMF, Rz. 146 - Khả năng truy vết, 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 giữ)
• UStG (§ 14 - Hóa đơn điện tử, § 14b - Lưu giữ)
• BMF-FAQ về hóa đơn điện tử (tình trạng 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 lưu trữ chứng từ, Sidecar

Topo họ nguồn và các liên kết tham chiếu CDN

Lưu ý: Sự phân công giữa nguồn, bản sao và trung tâm cộng đồng 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 về trạng thái hiện tại.