ED01 - Động lực: Tại sao một doanh nhân lại ghi nhật ký của mình trong Git

Vấn đề

Một doanh nhân sáng lập một tổ chức - và đứng trước một bức tranh không rõ ràng về những rủi ro sẽ phát sinh trong tương lai. Những nghĩa vụ nào phát sinh vào lúc nào? Những chứng từ nào phải được lưu giữ trong bao lâu? Những thời hạn nào có nguy cơ bị bỏ lỡ? Cơ quan nào sẽ liên hệ vào lúc nào về cuộc kiểm tra nào?

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

Giấy tờ ghi chép rời rạc và các danh sách Excel cục bộ - không thể kiểm chứng, không an toàn kiểm toán
Hỗn loạn PDF và E-mail trong các cuộc kiểm tra - hồ sơ được ghép nối ad-hoc
Các giải pháp ốc đảo (phần mềm lương ở đây, kế toán ở đó, kho lưu trữ chứng từ ở nơi khác) - không có chuỗi chứng cứ liền mạch
Khoảng trống mã nguồn mở đối với các nghĩa vụ đặc biệt (thời gian làm việc, chi phí công tác, phụ cấp, BEM, FZul/BSFZ, tư cách phi lợi nhuận) - ở đây hầu như không có sự hỗ trợ tự do nào
Tồn đọng rủi ro - các nghĩa vụ hôm nay bị bỏ qua một cách cheap, đến ngày mai trở nên đắt giá dưới dạng tiền phạt, phụ trội chậm trễ hoặc việc bị tước tư cách

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR A["Gründung
Tag 0"] --> B["Pflichten
unklar"] B --> C["Heute cheap
ignoriert"] C --> D["Morgen teuer
Bußgeld/Aberkennung"] D --> E["Risiko
realisiert"] style A fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style B fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style C fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style D fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style E fill:#FF3333,stroke:#0F1B33,color:#FBFAF7

Thông điệp cốt lõi

Không chỉ tài liệu phải an toàn kiểm toán - mà cả các quyết định, thời hạn và tham chiếu chứng từ cũng phải truy vết được, tái lập được và kiểm toán được. Một nhật ký thuần Git làm đúng điều đó: nó biến những sự kiện được ghi nhận hôm nay một cách cheap (giá rẻ) (một mục JSON với V7GUID + tham chiếu chứng từ SHA-256) thành những bằng chứng an toàn kiểm toán trong tương lai. Tuân thủ trở thành đòn bẩy, chứ không phải cái phanh.

Compliance by Design: "Bức tranh không rõ ràng" về các rủi ro tương lai được giảm thiểu ngay từ đầu bằng các kỹ thuật GitCover (OSCAL, OPA, V7GUID, Git-Hooks), chứ không đợi đến khi kiểm soát viên gõ cửa.

Nguồn gốc: Cuộc kiểm tra an sinh xã hội như chất kích hoạt thực tiễn

Ý tưởng GitCover không được sinh ra trong tháp ngà, mà từ những trải nghiệm thực tiễn cụ thể: gần nhất là từ một cuộc kiểm tra doanh nghiệp về an sinh xã hội (SV) tại một UG siêu nhỏ (ở đây được ẩn danh hóa là ORG-V, nghĩa là "tổ chức tiền thân") cho giai đoạn 2021–2023; diễn ra trong khoảng thời gian 02/2024–03/2025. Cuộc kiểm tra đã bộc lộ những điểm đau mà các kỹ thuật GitCover hướng đến giải quyết.

Dòng thời gian của cuộc kiểm tra SV

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% timeline title SV-Prüfung ORG-V - Genese der GitCover-Idee section 2024 - Prüfung angekündigt Feb 2024 : DRV kündigt BP nach § 28p SGB IV an Dez 2024 : Unterlagen-Anforderung (Lohnkonten 2021–2023) Dez 2024 : Versand als PDF/ZIP per E-Mail section 2025 - Prüfung abgeschlossen Feb 2025 : DRV übermittelt Prüfergebnisse (Anhörung § 24 SGB X) Feb 2025 : Akzeptanz ohne Einwände Mär 2025 : SV-Prüfung abgeschlossen : GitCover-Idee geboren section 2025 - Ableitungen Q1 2025 : AuditPrep-Modul konzipiert Q2 2025 : Intensive F&E Q3 2025 : V7GUID/GCEP DPMA-Anmeldungen

Điều gì đã xảy ra?

Ngày	Sự kiện	Trạng thái
02/2024	DRV thông báo kiểm tra doanh nghiệp theo § 28p SGB IV	⏳
12/2024	DRV yêu cầu hồ sơ kiểm tra (tài khoản lương 2021–2023, bảng câu hỏi, thư đi kèm)	⏳
12/2024	Hồ sơ được ghép nối thành PDF/ZIP và gửi qua E-mail	✅
02/2025	DRV chuyển giao kết quả kiểm tra (nghe ý kiến theo § 24 SGB X, bảng tổng hợp số liệu, phụ lục HEK/Minijob-Zentrale)	✅
02/2025	Chấp nhận không có phản đối; đã nộp đơn hoàn trả tại KK	✅
03/2025	Kiểm tra an sinh xã hội hoàn tất - ý tưởng GitCover ra đời	✅

Kết quả tài chính (ròng)

Khoản mục	Số tiền
Hoàn trả khoản đóng U1 đã nộp thừa	+121 EUR
Truy thu khoản đóng cố định KV	−30 EUR
Hoàn trả ròng	+91 EUR
Chi phí nhà cung cấp dịch vụ	>100 EUR
Công sức	nhiều ngày tổng hợp thủ công

Những điểm đau - điều cuộc kiểm tra đã bộc lộ

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR P1["Kein Büro/Fax/Mitarbeiter
Prüfung nur per E-Mail"] P2["Beleg-Echtheit unklar
PDFs ohne kryptographische Verankerung"] P3["Keine Nachweiskette
Lohnkonten/SV/Erstattung an verschiedenen Orten"] P4["Fristen ad-hoc
manuell im Kalender gepflegt"] P5["Audit-Export fehlt
euBP/eXTra, Z3 nur mit Spezialsoftware"] P6["Lohn-Account pausiert
nach Mitarbeiter-Ausscheiden
Extra-Kosten > Erstattung"] P7["Alte Sicherungen
alter Software-Stand
GoBD-Auflage verletzt"] P1 --> G["GitCover-Idee
geboren"] P2 --> G P3 --> G P4 --> G P5 --> G P6 --> G P7 --> G G --> S["GitCover-Lösungen
SHA-256+V7GUID, Hooks, Fristen-Check
Evidence-Packages, Git-Bundles self-contained"] style P1 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P2 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P3 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P4 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P5 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P6 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P7 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style G fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style S fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33

Không có văn phòng, không có fax, không có nhân viên - và vẫn phải xử lý một cuộc kiểm tra doanh nghiệp thuần túy qua E-mail với các tệp PDF và ZIP. Các công cụ cho trường hợp siêu nhỏ này không tồn tại.
Tính xác thực của chứng từ không rõ ràng - PDF gửi qua E-mail không có neo giữ bằng mật mã. Ai đã thay đổi cái gì vào lúc nào? Giá trị chứng cứ chỉ được bảo đảm nhờ khả năng truy vết thủ công.
Không có chuỗi chứng cứ liền mạch - tài khoản lương, các thông báo SV, chứng minh khoản đóng góp và chứng từ hoàn trả nằm ở những nơi khác nhau, không có tham chiếu chéo. Mỗi lần cần làm rõ lại đòi hỏi phải tìm kiếm từ đầu.
Quản lý thời hạn ad-hoc - thời hạn nghe ý kiến, thời hạn hoàn trả, thời hạn phản đối được quản lý thủ công trong lịch. Không có cảnh báo khi thời hạn sắp trôi qua.
Thiếu xuất dữ liệu kiểm toán - DRV yêu cầu dữ liệu theo định dạng euBP (eXTra V3.4.0); cơ quan thuế (FA) có thể đã yêu cầu một phương tiện dữ liệu Z3. Cả hai đều chỉ khả thi với phần mềm chuyên dụng hoặc chuẩn bị thủ công.
Nhân viên nghỉ việc → tài khoản lương bị tạm dừng - sau khi nhân viên khi đó nghỉ việc, tài khoản tính lương tại nhà cung cấp dịch vụ đã bị tạm dừng. Ai lại duy trì một tài khoản đám mây vô dụng một cách tốn kém khi lý do không còn tồn tại (nhân viên đã nghỉ, không còn cần tính lương)? Nhưng việc tổng hợp gói hồ sơ cho cuộc kiểm tra lại đòi hỏi chi phí phát sinh bổ sung tại nhà cung cấp dịch vụ, mà cuối cùng cao hơn khoản "hoàn trả" nhỏ nhoi ở cuối cuộc kiểm tra.
Kích hoạt lại các bản sao lưu cũ với phiên bản phần mềm cũ - để các tài khoản lương 2021–2023 có thể truy cập trở lại, các bản sao lưu cũ phải được kích hoạt lại với phiên bản phần mềm cũ - một vấn đề thực tiễn đáng kể. Về hình thức, đây là một hành vi vi phạm quy định về yêu cầu GoBD, vì cũng phải bảo đảm về mặt kỹ thuật rằng trong thời gian lưu giữ dài (10 năm) luôn có thể truy cập được. Trên thực tế, nghĩa vụ này mâu thuẫn với áp lực quản trị kinh doanh là không duy trì các tài khoản đám mây không sử dụng một cách tốn kém. Chính sự căng thẳng này là một động cơ cốt lõi của GitCover: Git-Bundles là self-contained - chúng không cần tài khoản đám mây, không cần hợp đồng nhà cung cấp dịch vụ, không cần phiên bản phần mềm. Chỉ cần một lệnh git clone là đủ, và thời hạn lưu giữ được đáp ứng về mặt kỹ thuật.

Cơ sở pháp lý: AO § 146, § 147 và GoBD

"Hành vi vi phạm quy định về yêu cầu GoBD" được đề cập ở điểm 7 có cơ sở pháp lý rõ ràng - trong Abgabenordnung (AO) và trong GoBD (Các nguyên tắc về quản lý và lưu giữ đúng quy định sổ sách, ghi chép và tài liệu ở dạng điện tử cũng như về truy cập dữ liệu, Công văn BMF).

AO § 146 Abs. 5 - Tính sẵn sàng trong thời hạn lưu giữ

"Khi dẫn sổ sách và các ghi chép khác cần thiết trên các phương tiện dữ liệu, phải bảo đảm đặc biệt rằng trong suốt thời hạn lưu giữ, dữ liệu luôn sẵn sàng và có thể được đọc ra ngay lập tức."

Đây là quy định cốt lõi: Ai hạch toán bằng phương tiện điện tử phải bảo đảm trong toàn bộ thời hạn lưu giữ (10 năm cho sổ sách/ghi chép, 8 năm cho chứng từ hạch toán, § 147 Abs. 3 AO) rằng dữ liệu luôn sẵn sàng và đọc được ngay lập tức. Một tài khoản đám mây bị tạm dừng, chỉ được kích hoạt lại với chi phí phát sinh, vi phạm nghĩa vụ này - dữ liệu không "luôn sẵn sàng", mà chỉ có khi trả tiền và với sự chậm trễ.

AO § 147 Abs. 2 - Lưu giữ trên các phương tiện dữ liệu

"Ngoại trừ các báo cáo tài chính năm [...], các tài liệu được liệt kê trong Absatz 1 cũng có thể được lưu giữ dưới dạng tái hiện trên một phương tiện hiển thị hình ảnh hoặc trên các phương tiện dữ liệu khác, nếu điều này phù hợp với các nguyên tắc kế toán đúng quy định và được bảo đảm rằng bản tái hiện hoặc dữ liệu [...] trong suốt thời hạn lưu giữ luôn sẵn sàng, có thể được đọc ra ngay lập tức và có thể được xử lý bằng máy."

Một lần nữa: "luôn sẵn sàng", "đọc được ngay lập tức", "xử lý được bằng máy". Một phiên bản phần mềm cũ phải kích hoạt lại trước thì không đáp ứng được "ngay lập tức".

AO § 147 Abs. 5 - Phương tiện hỗ trợ bằng chi phí của người nộp thuế

"Ai nộp các tài liệu cần lưu giữ dưới dạng tái hiện trên một phương tiện hiển thị hình ảnh hoặc trên các phương tiện dữ liệu khác, thì có nghĩa vụ cung cấp bằng chi phí của mình những phương tiện hỗ trợ cần thiết để làm cho các tài liệu đó đọc được."

Điều đó có nghĩa là: Nếu nhà cung cấp dịch vụ không còn duy trì hệ thống cũ, doanh nhân phải tự mình cung cấp các phương tiện hỗ trợ (phần mềm, giấy phép, phần cứng) để làm cho dữ liệu đọc được. Chính đó là vấn đề thực tiễn trong trường hợp nguồn gốc: bản sao lưu cũ, phiên bản phần mềm cũ, không còn phương tiện hỗ trợ nào khả dụng.

AO § 147 Abs. 6 - Truy cập dữ liệu trong kiểm tra thuế

"Nếu các tài liệu theo Absatz 1 đã được tạo ra với sự trợ giúp của một hệ thống xử lý dữ liệu, thì trong khuôn khổ một cuộc kiểm tra thuế, cơ quan tài chính có thể [...] yêu cầu rằng dữ liệu được cung cấp dưới dạng đã được xử lý bằng máy theo các quy định của cơ quan này."

Trong một cuộc kiểm tra thuế, doanh nhân phải cung cấp dữ liệu xử lý được bằng máy - không phải dưới dạng bản in PDF, mà là dữ liệu có cấu trúc. Một tài khoản đám mây bị tạm dừng, chỉ cung cấp xuất PDF, là không đủ.

GoBD - Tài liệu hóa quy trình và thay đổi hệ thống

GoBD cụ thể hóa các quy định AO này cho các hệ thống điện tử. Các yêu cầu then chốt:

Tài liệu hóa quy trình (GoBD Rz. 64–91): Mỗi hệ thống kế toán điện tử phải có tài liệu hóa quy trình, mô tả quy trình, môi trường hệ thống, các biện pháp tổ chức và các kiểm soát nội bộ. Khi thay đổi hệ thống, tài liệu hóa quy trình phải được cập nhật tiếp.
Thay đổi hệ thống/Di chuyển (GoBD Rz. 146–150): Khi thay đổi hệ thống, phải bảo đảm rằng dữ liệu của hệ thống cũ tiếp tục khả dụng, đọc được và xử lý được bằng máy. Tài liệu hóa quy trình phải ghi nhận việc thay đổi này.
Tính không thể thay đổi (GoBD Rz. 146): Sau khi hạch toán, dữ liệu không được thay đổi. Các chỉnh sửa phải được thực hiện dưới dạng các mục mới kèm lý do.

Các hậu quả lý thuyết khi vi phạm

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR V["Verstoß gegen
AO § 146/147 + GoBD"] V --> K1["Verspätungszuschlag
§ 152 AO
bis 25.000 EUR"] V --> K2["Schätzung
§ 162 AO
bei nicht verwertbaren Daten"] V --> K3["Verzögerungsgeld
§ 146 Abs. 2c AO
2.500–250.000 EUR"] V --> K4["Beweislastumkehr
FA schätzt, Unternehmer
muss widerlegen"] V --> K5["Ordnungswidrigkeit
§ 379 AO
Bußgeld bis 50.000 EUR"] V --> K6["Steuerstrafverfahren
§ 370 AO
bei vorsätzlicher Verkürzung"] style V fill:#FF1A1A,stroke:#0F1B33,color:#FBFAF7 style K1 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K2 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K3 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K4 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K5 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K6 fill:#FDBA74,stroke:#C2410C,color:#0F1B33

Hậu quả	Cơ sở pháp lý	Mức độ/Rủi ro
Phụ trội chậm trễ	§ 152 AO	tối đa 25.000 EUR (từng trường hợp)
Ước tính căn cứ tính thuế	§ 162 AO	Cơ quan thuế ước tính khi dữ liệu không thể sử dụng - thường bất lợi cho doanh nhân
Tiền phạt do chậm trễ	§ 146 Abs. 2c AO	2.500–250.000 EUR (khi chuyển giao ra ngoài không được phê duyệt)
Đảo ngược gánh nặng chứng minh	§ 162 AO, § 90 AO	Doanh nhân phải bác bỏ bản ước tính - gần như không thể khi thiếu dữ liệu
Hành vi vi phạm hành chính	§ 379 AO	Tiền phạt tối đa 50.000 EUR (cố ý hoặc do sơ suất)
Thủ tục hình sự về thuế	§ 370 AO	Án tù tối đa 5 năm (khi trốn thuế cố ý)

Đánh giá thực tiễn: Trong trường hợp nguồn gốc, cuộc kiểm tra an sinh xã hội được chấp nhận mà không có phản đối - không có hậu quả nào xảy ra. Nhưng đó là may mắn: Nếu DRV không chấp nhận dữ liệu dưới dạng PDF mà khăng khăng đòi xử lý bằng máy (§ 147 Abs. 6 AO), doanh nhân đã rơi vào thế phải giải thích. Việc lưu giữ phù hợp GoBD không phải là nghĩa vụ lý thuyết - nó trở thành hiện thực trong mỗi cuộc kiểm tra thuế.

Tại sao Git giải quyết được vấn đề

Git đáp ứng các yêu cầu AO/GoBD by Design:

Yêu cầu AO/GoBD	Git đáp ứng như thế nào
"luôn sẵn sàng" (§ 146 Abs. 5)	`git clone` có thể thực hiện bất cứ lúc nào - không cần tài khoản đám mây, không cần giấy phép
"đọc được ngay lập tức" (§ 147 Abs. 2)	Các tệp văn bản thuần (Markdown, JSON) - không cần phiên bản phần mềm nào
"xử lý được bằng máy" (§ 147 Abs. 6)	JSON-Schema-First - dữ liệu có cấu trúc, không cần xuất PDF
"Phương tiện hỗ trợ bằng chi phí của doanh nhân" (§ 147 Abs. 5)	Git là OSS, miễn phí - không có chi phí nhà cung cấp dịch vụ
Tính không thể thay đổi (GoBD Rz. 146)	Tags, Protected Branches, đánh dấu lỗi thời
Tài liệu hóa quy trình (GoBD Rz. 64–91)	Chính repo là tài liệu quy trình - `git log` hiển thị quy trình
Thay đổi hệ thống/Di chuyển (GoBD Rz. 146–150)	Git độc lập với phiên bản - `git clone` trên mọi hệ thống

Hóa đơn điện tử: Các định dạng XML là tài liệu gốc theo AO

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 giữa các doanh nghiệp trong nước (§ 14 UStG, Wachstumschancengesetz). 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 và cho phép xử lý điện tử (§ 14 Abs. 1 Satz 3 UStG). Một tài liệu PDF đơn giản không còn thuộc diện này nữa - kể từ năm 2025, nó là một "hóa đơn khác".

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR P["Papierrechnung
vor 2025"] --> U["Übergang
2025–2027"] PDF["PDF per E-Mail
vor 2025 'elektronisch'"] --> U U --> E["E-Rechnung
ab 2025 verpflichtend
strukturiert, maschinenlesbar"] E --> X["XRechnung
XML-basiert
EN 16931"] E --> Z["ZUGFeRD
hybrid: PDF + XML
ab v2.0.1"] style P fill:#E5E7EB,stroke:#6B7280,color:#0F1B33 style PDF fill:#E5E7EB,stroke:#6B7280,color:#0F1B33 style U fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style E fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style X fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style Z fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33

XML là tài liệu gốc - không phải PDF

Điểm quyết định cho việc lưu giữ: Với hóa đơn điện tử, phần có cấu trúc (XML) là tài liệu gốc theo nghĩa của AO, chứ không phải một tệp PDF đính kèm hoặc một hình ảnh đọc được bằng mắt. BMF làm rõ (FAQ về hóa đơn điện tử, Câu hỏi 13):

"Với một hóa đơn điện tử, ít nhất phần có cấu trúc của nó phải được lưu giữ sao cho nó nguyên vẹn ở hình thức ban đầu."

Điều đó có nghĩa là:

XRechnung (dựa trên XML, EN 16931): Tệp XML là tài liệu gốc. Nó phải được lưu giữ không thay đổi. Bản hiển thị PDF chỉ là một hiển thị hỗ trợ - nó không thay thế XML.
ZUGFeRD (lai: PDF + XML nhúng): Khi có sai khác giữa phần XML và phần hình ảnh, kể từ năm 2025 phần có cấu trúc (XML) là phần có giá trị quyết định (BMF FAQ Câu hỏi 12a). Hình ảnh PDF không còn là phần dẫn dắt nữa.

AO § 147 - Hóa đơn điện tử là chứng từ hạch toán

Hóa đơn điện tử là chứng từ hạch toán theo nghĩa của § 147 Abs. 1 Nr. 4 AO và do đó phải được lưu giữ tám năm (§ 147 Abs. 3 AO). Với tư cách tài liệu điện tử, các yêu cầu AO/GoBD được áp dụng:

Luôn sẵn sàng (§ 147 Abs. 2): Tệp XML phải có thể truy cập trong suốt thời hạn lưu giữ.
Đọc được ngay lập tức (§ 147 Abs. 2): Một trình xem XML hoặc trình xem hóa đơn điện tử ELSTER (www.e-rechnung.elster.de) làm cho tệp đọc được - nhưng bản thân XML là văn bản thuần và do đó cũng đọc được mà không cần phần mềm chuyên dụng.
Xử lý được bằng máy (§ 147 Abs. 6): XML theo định nghĩa là đọc được bằng máy - lý tưởng cho § 147 Abs. 6 (truy cập dữ liệu trong kiểm tra thuế).
Nguyên vẹn (§ 14b Abs. 1 UStG): Tệp XML không được thay đổi. Git đáp ứng điều này nhờ tính không thể thay đổi sau Commit (băm SHA-256).

Các quy định toàn EU: EN 16931 và Chỉ thị 2014/55/EU

Hóa đơn điện tử dựa trên pháp luật EU:

Chỉ thị 2014/55/EU - buộc các bên giao thầu công phải nhận và xử lý hóa đơn điện tử (B2G).
EN 16931 (bộ tiêu chuẩn châu Âu) - định nghĩa mô hình dữ liệu ngữ nghĩa cho hóa đơn điện tử (CEN/TC 434). XRechnung và ZUGFeRD là các bản triển khai quốc gia của tiêu chuẩn EN này.
ViDA (VAT in the Digital Age) - kế hoạch mở rộng nghĩa vụ hóa đơn điện tử trên phạm vi EU và giới thiệu một hệ thống báo cáo cho dữ liệu giao dịch. Nghĩa vụ hóa đơn điện tử của Đức chuẩn bị cho ViDA.

Tại sao Git lý tưởng cho hóa đơn điện tử

Yêu cầu về hóa đơn điện tử	Git đáp ứng như thế nào
XML là tài liệu gốc	Tệp XML được lưu trong repo không thay đổi - `git diff` không hiển thị thay đổi nào
Nguyên vẹn (§ 14b UStG)	Băm SHA-256 cho mỗi Commit - mọi thay đổi đều sẽ nhìn thấy được
Lưu giữ 8 năm (§ 147 Abs. 3)	Git-Bundle như một kho lưu trữ self-contained - không cần tài khoản đám mây
Xử lý được bằng máy (§ 147 Abs. 6)	XML theo định nghĩa là đọc được bằng máy - `git grep` là đủ
Xác thực EN 16931	Pre-Commit-Hook có thể gọi trình xác thực XRechnung/ZUGFeRD
Hiển thị (BMF FAQ 12a)	XML + Markdown-Sidecar đọc được bằng mắt - cả hai đều trong repo
Thời hạn chuyển tiếp 2025–2027	Repo có thể lưu giữ song song cả "hóa đơn khác" (PDF) lẫn hóa đơn điện tử (XML)

Mẹo thực tiễn: Một Git-Repo có thể lưu giữ song song hóa đơn điện tử (XML) và hóa đơn khác (PDF) - 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 xem hóa đơn điện tử có cấu trúc XML hợp lệ hay không (schema XRechnung/ZUGFeRD). Nhờ đó, thời hạn chuyển tiếp 2025–2027 được bắc cầu mà không bị đứt gãy phương tiện.

Các dẫn xuất trực tiếp trong GitCover

Điểm đau	Khái niệm GitCover	Bài viết trong chuỗi
Tính xác thực của chứng từ không rõ ràng	SHA-256 + V7GUID + Sidecar `.v7g.md` cho mỗi chứng từ	ED03, ED08
Không có chuỗi chứng cứ	Git-Repo với các Hook chuyên biệt theo chức năng, Grundbuch dưới dạng JSON	ED06, ED07
Thời hạn ad-hoc	`checks/FRISTEN_CHECK.md` + cảnh báo tự động	ED09
Thiếu xuất dữ liệu kiểm toán	GoBDExport (Z3), EuBPExport (eXTra), Evidence-Packages	ED08, ED35
Tài khoản lương bị tạm dừng, chi phí phát sinh	Git-Bundles self-contained, không có tài khoản đám mây	ED08, ED09
Bản sao lưu cũ/phiên bản phần mềm cũ, vi phạm GoBD	Git-Repo như phương tiện lưu giữ self-contained, `git clone` là đủ	ED08, ED09
Ai đứng sau công ty?	Transparenzregister: xác định wB, ghi nhận, báo cáo	ED04, ED12, ED17, ED18
Không có OSS cho các trường hợp đặc biệt	GitCover bao phủ FZul/BSFZ, tư cách phi lợi nhuận, thời gian làm việc, BEM	ED25–ED34

Lưu ý - Nghĩa vụ của doanh nhân siêu nhỏ kể từ nhân viên thứ 1: Thường thì chính các doanh nhân siêu nhỏ đã chịu những nghĩa vụ như vậy kể từ nhân viên thứ 1 - ghi chép thời gian làm việc (ArbZG), tài liệu hóa lương tối thiểu (MiLoG), nghỉ phép/ốm đau/BEM (BUrlG/EFZG/SGB IX), đăng ký an sinh xã hội (SGB IV). Do đó, các nghĩa vụ kể từ nhân viên thứ 1 được đề cập trong Phần IV không phải là chủ đề đặc biệt của doanh nghiệp lớn, mà đúng là áp dụng cho các cơ sở siêu nhỏ và nhỏ lần đầu tuyển dụng nhân sự. GitCover cố ý hướng đến ngưỡng này - bước chuyển từ doanh nhân cá nhân sang người sử dụng lao động là thời điểm then chốt, khi các nghĩa vụ tuân thủ tăng vọt. Các nghĩa vụ kể từ đăng ký kinh doanh (phân loại Sphären, miễn trừ VBG, Pauschalen) đã được đề cập trong Phần II - chúng phát sinh mà không cần nhân viên.

Tại sao dùng Git làm phương tiện nhật ký?

Ban đầu Git là một hệ thống kiểm soát phiên bản - nhưng nó mang theo ba đặc tính khiến nó by Design phù hợp cho mục đích tuân thủ:

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR G["Git als
Tagebuch-Medium"] G --> U["Unveränderbarkeit
nach Freigabe
(Tags, Protected Branches)"] G --> N["Nachvollziehbarkeit
Autor + Zeitstempel
+ kryptographische Integrität"] G --> D["Dezentralität
Git-Bundles + GCEP
Multi-Site, Off-Site"] U --> GoBD["GoBD Rz. 146
konform"] N --> Audit["Audit-Ready
reproduzierbar"] D --> Backup["Kein SPOF
verteilt"] style G fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style U fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style N fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style D fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style GoBD fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style Audit fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style Backup fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33

Tính không thể thay đổi sau khi phát hành - Tags và Protected Branches bảo đảm rằng các mục nhật ký đã phát hành không bị thay đổi sau đó (GoBD Rz. 146). Các chỉnh sửa được thực hiện dưới dạng các Commit mới với đánh dấu lỗi thời.
Khả năng truy vết - mỗi Commit mang tác giả, dấu thời gian và tính toàn vẹn mật mã. Toàn bộ lịch sử đều có thể tái lập.
Tính phi tập trung - Git-Bundles và GCEP (Advisory Locks) cho phép lưu trữ phân tán (Multi-Site, sao lưu Off-Site) mà không có Single-Point-of-Failure tập trung.

Compliance by Design - các kỹ thuật GitCover

Chuỗi bài viết cho thấy các kỹ thuật sau đây giảm thiểu "bức tranh không rõ ràng" về các rủi ro tương lai ngay từ đầu như thế nào:

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TD CBD["Compliance by Design"] CBD --> OSCAL["OSCAL
maschinenlesbare
Compliance-Statements"] CBD --> OPA["OPA/Rego
Policy as Code
automatisierte Prüfung"] CBD --> V7["V7GUID Uniqueness
zeitstabile
eindeutige IDs"] CBD --> HOOKS["Git-Hooks
funktional dediziert
Pre/Post-Commit"] CBD --> ART["Code-Artefact-Typen
JSON-Schema-First
Sidecar-Pflicht"] OSCAL --> ZERT["Zertifizierungsreife
ISO 27001, AI Act, BSI GS++"] OPA --> POLICY["Sphären, Fristen,
Beitragsgruppen-Plausibilität"] V7 --> UNIQ["Kollisionsfrei,
sortierbar, dateiname-unabhängig"] HOOKS --> CHECK["Schema, Sphären,
Obsoleszenz geprüft"] ART --> SIG["Temporale Signatur
SHA-256-Belegreferenzen"] style CBD fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style OSCAL fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style OPA fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style V7 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style HOOKS fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style ART fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style ZERT fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style POLICY fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style UNIQ fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style CHECK fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SIG fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33

OSCAL - các tuyên bố tuân thủ đọc được bằng máy (độ sẵn sàng chứng nhận cho ISO 27001, AI Act, BSI GS++)
OPA/Rego - Policy as Code, kiểm tra chính sách tự động (tách biệt Sphären, thời hạn, tính hợp lý của nhóm đóng góp)
V7GUID Uniqueness - các định danh ổn định theo thời gian, duy nhất, vượt ra ngoài tên tệp (dựa trên UUIDv7, có thể sắp xếp, không xung đột)
Git-Hooks (chuyên biệt theo chức năng/theo nội dung) - Pre-Commit kiểm tra tách biệt Sphären, tuân thủ Schema, trạng thái lỗi thời; Post-Commit tạo các chỉ mục và cập nhật thời hạn
Các loại Code-Artefact và các mục - JSON-Schema-First, nghĩa vụ Sidecar, chữ ký thời gian {YYMMDD HHmm}, các tham chiếu chứng từ SHA-256

Nguyên tắc cốt lõi về khả năng truy vết thời gian: Thời gian ghi nhận không phải là một trường riêng biệt, mà được neo ngay trong uuidV7, dưới dạng dấu thời gian 48-bit theo RFC 9562 §5.7. uuidV7 được tạo ra từ một dấu thời gian được chỉ định trước (không phải now()) thông qua GitCover Helper (UuidV7Gen), phần còn lại được điền bằng giá trị ngẫu nhiên. Nhờ đó, thời gian ghi nhận được liên kết bằng mật mã với định danh của Artifact và không thể bị thay đổi về sau. Một biểu diễn chuỗi datetime/date riêng biệt là dư thừa và không được đưa vào các sự kiện - biểu diễn chuỗi cho DTO/HTMX là trách nhiệm của Harness.

Liên hệ RFC: Thành phần dấu thời gian 48-bit của uuidV7 tương ứng với RFC 9562 §5.7 (UUIDv7) - mili giây Unix kể từ Epoch (1970-01-01T00:00:00Z), 48 bit, miền giá trị 0 … 2⁴⁸−1 (phạm vi đến khoảng năm 10889). Đặc tả V7GUID được lưu trữ mang tính chuẩn tắc tại work/OSS/TOP/.gitcover/specs/v7guid/; đơn đăng ký sáng chế liên quan là DPMA Az. 10 2025 003 091.6.

Các Helper-Routine (GitCover OSS Tools): Trong work/OSS/TOP/tools/UuidV7Gen/ có một OSS-Helper cung cấp hai thao tác trung tâm:

gen - tạo ra một uuidV7 qua Guid.CreateVersion7() (.NET) (với dấu thời gian được chỉ định trước khi cần, không chỉ now()) và trả về Label, UUID và dấu thời gian ISO đã giải mã.

decode - trích xuất thành phần dấu thời gian 48-bit từ một uuidV7 cho trước và trả về nó dưới dạng dấu thời gian ISO-8601.

Các Helper này rất quan trọng để tạo ra một khóa uuidV7 hợp lệ từ các Fremd-Keys (ví dụ: một dấu thời gian trong dữ liệu hoặc trong tên tệp) - đồng thời tài liệu hóa các yêu cầu thời gian của GoBD (ghi nhận kịp thời, khả năng truy vết). Giá trị 48-bit là yếu tố duy nhất trong việc suy dẫn TenantId và thay vì thời gian hệ thống, nó cũng có thể là một thời điểm được chỉ định rõ ràng (ví dụ: từ một dấu thời gian của chứng chỉ ELSTER, ngày trên một biên lai có TSE, v.v.) - cách diễn giải tuân theo tài liệu hóa quy trình.

Nguyên tắc Sidecar (.v7g.md): Mỗi Sidecar mang một Composite Key V7GUID:uuidV7:

V7GUID (Class Identifier) - phân loại Sidecar dựa theo .gitcover Registry (cái gì/loại nào)

uuidV7 (Object ID) - định danh của chính Sidecar, được tạo với dấu thời gian được chỉ định trước/dấu thời gian 48-bit được neo trong GUID

v7g_taxonomy[].v7guid - Object ID của tài liệu được phân loại

sha256 - định danh của tài liệu gốc được phân loại — bằng chứng cho tính nguyên bản, luôn luôn và ở mọi nơi (ngay cả khi tài liệu di chuyển: độc lập với đường dẫn/tên, được tính từ nội dung)

Nhờ đó, không chỉ tài liệu được định danh duy nhất (qua SHA-256 của nó), mà cả hành động phân loại tự thân - bao gồm thời điểm (trong uuidV7), ai đã phân loại và với vai trò nào. Không có trường datetime riêng biệt.

Risiko-Leverage - cái gì hôm nay giá rẻ (cheap) sẽ trở nên an toàn kiểm toán vào ngày mai

Risiko-Leverage: Những sự kiện được ghi nhận hôm nay với chi phí tối thiểu (vài phút, qua các 'Agent' chỉ vài khoảnh khắc) sẽ trở thành những bằng chứng an toàn kiểm toán trong tương lai (vài giờ kiểm tra). Doanh nhân "nâng" một vị thế gánh nặng chứng minh - Compliance như một đòn bẩy.

Hôm nay (cheap, ~phút/giây)	Ngày mai (an toàn kiểm toán, ~giờ kiểm tra)	Rủi ro được giảm thiểu
Mục nhật ký JSON với V7GUID + SHA-256	Bằng chứng phù hợp GoBD (10 năm)	Vi phạm thời hạn lưu giữ
Trường `source` cho mỗi sự kiện	Gánh nặng chứng minh trong kiểm tra FA/SV	Hạ cấp giá trị chứng cứ
Tệp kiểm tra thời hạn	Tránh được việc bỏ lỡ thời hạn	Phụ trội chậm trễ § 152 AO
Tag Sphären cho mỗi mục	Tư cách phi lợi nhuận được bảo vệ	Bị tước tư cách § 51 AO
Nhật ký chứng minh giờ cho FZul	Có thể đạt được chứng nhận BSFZ	Mất FZul (tối đa 1 triệu EUR)
Sidecar `.v7g.md` cho mỗi chứng từ	Tính xác thực của chứng từ chứng minh được	Sự bác bỏ giá trị chứng cứ
JSON thời gian làm việc cho mỗi ngày	Tuân thủ ArbZG chứng minh được	Tiền phạt § 22 ArbZG
Git-Bundle thay vì tài khoản đám mây	Lưu giữ không tốn chi phí nhà cung cấp	Mất quyền truy cập GoBD sau khi tài khoản bị tạm dừng
`git clone` thay vì kích hoạt lại phiên bản phần mềm	Lưu giữ self-contained, không phụ thuộc phiên bản	Vi phạm GoBD do các hệ thống cũ không thể kích hoạt lại

Chuỗi bài viết này cho thấy điều gì

Chuỗi bài viết theo chân một doanh nhân hư cấu (E1), người điều hành một tổ chức KMU (trình giữ chỗ, mở về hình thức pháp lý) và ghi nhật ký của mình trong một Git-Repo. Cấu trúc dựa trên một khái niệm SSoT có thật, nhưng được ẩn danh hóa hoàn toàn - tất cả dữ liệu về cá nhân, công ty, HRB, IBAN, số thuế đều được thay bằng trình giữ chỗ.

Lưu ý DSGVO: Tất cả các liên hệ đến cá nhân/công ty trong chuỗi bài viết này đều là hư cấu hoặc đã được ẩn danh hóa. Mọi điểm tương đồng với các tổ chức thật là ngẫu nhiên và không có chủ ý.

Xem trước chuỗi bài viết

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR I["Teil I
Grundlagen
ED01–ED04"] II["Teil II
GoBD, AO, Finanzamt
+ Pflichten ab Gewerbeanmeldung
ED05–ED12"] III["Teil III
Behörden & Verbände
ED13–ED19"] IV["Teil IV
Mitarbeiter & Lohn
+ Pflichten ab 1. Mitarbeiter
ED20–ED27"] I --> II --> III --> IV style I fill:#E5E7EB,stroke:#6B7280,color:#0F1B33 style II fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style III fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style IV fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR V["Teil V
Besondere Herausforderungen
FZul/BSFZ, Gemeinnützigkeit
ED28–ED31"] VI["Teil VI
Harness-Anforderungen
ED32–ED35"] VII["Teil VII
Anhang
ED36–ED37"] V --> VI --> VII style V fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style VI fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style VII fill:#E5E7EB,stroke:#6B7280,color:#0F1B33

Phần	Chủ đề	Bài viết
I	Kiến thức nền tảng (bài viết này)	ED01–ED03
II	Quản trị doanh nghiệp: GoBD, AO, cơ quan thuế + nghĩa vụ kể từ đăng ký kinh doanh (Sphären, VBG, Pauschalen)	ED05–ED11
III	Các cơ quan nhà nước & hiệp hội	ED13–ED19
IV	Nhân viên & lương + nghĩa vụ kể từ nhân viên thứ 1 (thời gian làm việc, MiLoG, nghỉ phép/ốm đau/BEM)	ED20–ED27
V	Những thách thức đặc biệt (FZul/BSFZ, tư cách phi lợi nhuận)	ED28–ED31
VI	Yêu cầu Harness	ED32–ED35
VII	Phụ lục (Bảng thuật ngữ, Nguồn)	ED36–ED37

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

Có thể suy ra từ ED01:

ID	Yêu cầu	Mức ưu tiên
FA-1.1	Các mục nhật ký dưới dạng JSON-Artifacts (Schema-First)	MUST
FA-1.2	Composite Key `V7GUID` (Class) : `uuidV7` (Object) - không có trường `datetime`/`date` riêng biệt; thời gian nằm trong `uuidV7` (RFC 9562 §5.7)	MUST
FA-1.3	`uuidV7` được tạo từ dấu thời gian được chỉ định trước (không phải `now()`) thông qua Helper	MUST
FA-2.1	SHA-256 làm ID chứng từ	MUST
FA-2.2	Nghĩa vụ Sidecar `.v7g.md`	MUST
FA-4.1	Tệp kiểm tra thời hạn	MUST
TA-2.1	Pre-Commit: xác thực JSON-Schema	MUST

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

Nguồn

Chứng từ nguồn gốc của cuộc kiểm tra an sinh xã hội (đã ẩn danh hóa): AFJD/FY2025/BSFZ/Nachweise/00_BELEG_INVENTAR.md Mục J
GoBD (Công văn BMF ngày 28.11.2019, BStBl I S. 1269, sửa đổi lần cuối 14.07.2025, BStBl I S. 1502)
AO (§§ 146, 147, 152, 162, 370, 379)
SGB IV (§ 28p - Kiểm tra doanh nghiệp)
UStG (§ 14 - Hóa đơn điện tử, § 14b - Lưu giữ)
BMF-FAQ về hóa đơn điện tử (cập nhật tháng 3/2026, bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html)
EN 16931 (bộ tiêu chuẩn châu Âu, CEN/TC 434)
Chỉ thị 2014/55/EU (hóa đơn điện tử B2G)
RFC 9562 §5.7 (UUIDv7) - dấu thời gian Unix-ms 48-bit
Đặc tả V7GUID - work/OSS/TOP/.gitcover/specs/v7guid/ (chuẩn tắc)
DPMA Az. 10 2025 003 091.6 - Đơn đăng ký sáng chế V7GUID (Yêu cầu bảo hộ chính 2, các yêu cầu bảo hộ 5–8)
GitCover OSS Tool UuidV7Gen - work/OSS/TOP/tools/UuidV7Gen/ (các Helper-Routine gen/decode)
DSGVO (nghĩa vụ ẩn danh hóa khi công bố)

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

Vai trò	Địa điểm	Mục đích
Primary / SSoT	git.gitcover.org/GCC	Kho lưu trữ chính tắc (ký GPG, có phiên bản)
Public OSS Mirror / CDN	codeberg.org/gitcover-commons	Bản sao chỉ đọc; khám phá FLOSS
Community Hub	github.com/gitcover-commons	Issues & Discussions; tham chiếu mã nguồn trên Codeberg

Lưu ý: Việc phân bổ này giữa nguồn, Mirror và Community-Hub 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 tắc tương ứng tại git.gitcover.org/GCC để biết trạng thái hiện tại. nguồn chính tắc trên gitcover.org cho trạng thái hiện tại.