ED01 - Động lực: Vì sao một doanh nhân đưa nhật ký của mình vào Git

Vấn đề

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

Thực tiễn hiện nay trong lĩnh vực KMU được đặc trưng bởi:

Quản lý giấy tờ lộn xộn và các danh sách Excel cục bộ - không thể truy vết, không an toàn cho kiểm toán
Hỗn loạn PDF và email khi kiểm tra - tài liệu được gom lại tùy ứng biến
Giải pháp riêng lẻ (phần mềm lương ở đây, kế toán ở kia, kho chứng từ ở nơi khác) - không có chuỗi bằng chứng xuyên suốt
Lỗ hổng mã nguồn mở đối với các nghĩa vụ đặc biệt (thời giờ làm việc, chi phí đi lại, phụ cấp, BEM, FZul/BSFZ, mục đích công ích) - ở đây hầu như không có hỗ trợ miễn phí
Rủi ro tích tụ - hôm nay các nghĩa vụ bị bỏ qua một cách rẻ mạt, cho đến khi ngày mai chúng trở nên đắt đỏ dưới dạng tiền phạt, phụ phí chậm nộp hoặc bị tước công nhận

%%{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

Tuyên bố cốt lõi

Không chỉ tài liệu phải an toàn cho 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 có thể truy vết, tái tạo và kiểm toán được. Một nhật ký Git-native làm chính điều đó: nó biến các sự kiện được ghi nhận hôm nay một cách rẻ (giá thấp) (một mục JSON với V7GUID + tham chiếu chứng từ SHA-256) thành bằng chứng an toàn cho kiểm toán trong tương lai. Tuân thủ trở thành đòn bẩy, không phải phanh hãm.

Compliance by Design: "Hình ảnh không rõ ràng" về các rủi ro tương lai được giảm thiểu bằng các kỹ thuật GitCover (OSCAL, OPA, V7GUID, Git-Hooks) ngay từ đầu, không phải chỉ khi người kiểm tra bấm chuông.

Nhật ký như lịch làm việc doanh nghiệp

Nhật ký không phải sổ ghi chú riêng và cũng không phải lịch thời giờ làm việc được ghi bổ sung sau. Nó là SSoT thời gian của công việc: Lịch làm việc cho thấy hiệu suất, quyết định hoặc việc làm rõ nào đã phát sinh khi nào và dẫn về chứng từ, hợp đồng hoặc vụ việc nào. Nhờ đó, cùng một bằng chứng lao động có thể phục vụ nhiều mục tiêu khác nhau mà không phải dựng một câu chuyện mới cho mỗi cuộc kiểm tra:

BSFZ/FZulG: các dự án R&D, thời gian thực hiện và việc phân định được ghi nhận kịp thời.
FA/EStG/EÜR: lý do phát sinh trong hoạt động kinh doanh và các phần tư nhân/kinh doanh vẫn có thể truy vết.
USt: thời gian thực hiện, việc thực hiện hợp đồng và liên kết hóa đơn có thể được gắn kết.
GoBD/AO: chứng từ, quyết định, phê duyệt và thay đổi tạo thành một chuỗi ngược/xuôi.
Rủi ro và khả năng di chuyển: hoạt động kinh doanh không phụ thuộc vào trí nhớ của một cá nhân hoặc một cổng nhà cung cấp; các sự kiện nằm trong các Git artifact mở, được phiên bản hóa.

Quy tắc rất đơn giản: Nhật ký mô tả lịch làm việc; các repository lưu giữ bằng chứng. Một tác nhân chỉ được suy ra từ nhật ký những gì các tài liệu gốc và sidecar được liên kết mang theo. Như vậy, tuân thủ không được thực hiện như công việc bổ sung về sau, mà như một quy trình làm việc bình thường.

Nguồn gốc: cuộc kiểm tra SV như tác nhân 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 đây nhất là từ một cuộc kiểm tra doanh nghiệp SV tại một UG nhỏ nhất (ở đây được ẩn danh là ORG-V cho "tổ chức tiền thân") cho giai đoạn 2021–2023; diễn ra trong giai đoạn 02/2024–03/2025. Cuộc kiểm tra đã bộc lộ các điểm đau mà các kỹ thuật GitCover 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 tài liệu kiểm tra (tài khoản lương 2021–2023, bảng hỏi, thư kèm theo)	⏳
12/2024	Tài liệu được gom lại và gửi qua email dưới dạng PDF/ZIP	✅
02/2025	DRV gửi kết quả kiểm tra (phiên điều trần § 24 SGB X, bảng tổng hợp, phụ lục HEK/Minijob-Zentrale)	✅
02/2025	Được chấp nhận không có phản đối; đã nộp đơn hoàn trả tại KK	✅
03/2025	Cuộc kiểm tra SV 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 góp U1 đã trả thừa	+121 EUR
Yêu cầu bổ sung khoản đóng góp trọn gói 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

Điểm đau - những gì 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 hoạt động, không fax, không nhân viên - và dù vậy vẫn phải xử lý một cuộc kiểm tra doanh nghiệp hoàn toàn qua email với các tệp PDF và ZIP. Các công cụ không tồn tại cho trường hợp nhỏ nhất này.
Tính xác thực của chứng từ không rõ ràng - PDF qua email không có neo giữ bằng mật mã. Ai đã thay đổi cái gì khi nào? Giá trị chứng cứ chỉ được bảo đảm thông qua khả năng truy vết thủ công.
Không có chuỗi bằng chứng xuyên suốt - tài khoản lương, thông báo SV, chứng từ đóng góp và chứng từ hoàn trả nằm ở nhiều nơi khác nhau, không có tham chiếu chéo. Mỗi câu hỏi lại đòi hỏi tìm kiếm lại.
Quản lý thời hạn tùy ứng biến - thời hạn điều trần, thời hạn hoàn trả, thời hạn khiếu nại được duy trì thủ công trong lịch. Không có cảnh báo khi sắp hết hạn.
Thiếu xuất kiểm toán - DRV yêu cầu dữ liệu ở định dạng euBP (eXTra V3.4.0); FA sẽ yêu cầu một vật mang dữ liệu Z3. Cả hai chỉ có thể thực hiện với phần mềm chuyên dụng hoặc chuẩn bị thủ công.
Nhân viên rời đi → tài khoản lương bị tạm dừng - sau khi nhân viên khi đó rời đi, tài khoản thanh toán 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 không cần thiết gây phát sinh chi phí khi lý do không còn nữa (nhân viên đã rời đi, không còn cần thanh toán nữa)? Nhưng việc tổng hợp gói tài liệu cho cuộc kiểm tra sau đó lại đòi hỏi chi phí phát sinh thêm tại nhà cung cấp dịch vụ, cuối cùng cao hơn khoản "hoàn trả" nhỏ vào 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ũ - để làm cho các tài khoản lương 2021–2023 có thể truy cập 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ề mặt hình thức, đây là một vi phạm quy định đối với nghĩa vụ GoBD, 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. Trong thực tiễn, nghĩa vụ này xung đột với áp lực kinh tế doanh nghiệp là không duy trì các tài khoản đám mây không sử dụng theo cách gây phát sinh chi phí. Chính căng thẳng này là động lực cốt lõi cho 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. Một 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

"Vi phạm quy định đối với nghĩa vụ GoBD" được đề cập ở điểm 7 có một cơ sở pháp lý rõ ràng - trong Abgabenordnung (AO) và trong GoBD (các nguyên tắc 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ư truy cập dữ liệu, BMF-Schreiben).

AO § 146 Abs. 5 - Tính khả dụng trong thời hạn lưu giữ

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

Đây là quy định cốt lõi: Ai ghi sổ điện tử thì phải bảo đảm trong toàn bộ thời hạn lưu giữ (10 năm đối với sổ sách/ghi chép, 8 năm đối với chứng từ ghi sổ, § 147 Abs. 3 AO) rằng dữ liệu luôn sẵn có 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 khi trả thêm chi phí, vi phạm nghĩa vụ này - dữ liệu không "luôn sẵn có", mà chỉ sẵn có khi thanh toán và có độ trễ.

AO § 147 Abs. 2 - Lưu giữ trên vật mang dữ liệu

"Ngoại trừ báo cáo tài chính năm [...] các tài liệu được nêu trong khoản 1 cũng có thể được lưu giữ dưới dạng bản sao trên vật mang hình ảnh hoặc trên các vật mang 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 sao hoặc dữ liệu [...] trong suốt thời hạn lưu giữ luôn sẵn có, có thể được làm cho đọc được ngay lập tức và có thể được đánh giá bằng máy."

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

AO § 147 Abs. 5 - Phương tiện hỗ trợ do người nộp thuế chịu chi phí

"Người nộp các tài liệu phải lưu giữ dưới dạng bản sao trên vật mang hình ảnh hoặc trên các vật mang dữ liệu khác có nghĩa vụ cung cấp các phương tiện hỗ trợ cần thiết bằng chi phí của mình để 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ũ, thì 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 nữa.

AO § 147 Abs. 6 - Truy cập dữ liệu khi kiểm tra bên ngoài

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

Khi kiểm tra bên ngoài, doanh nhân phải cung cấp dữ liệu có thể đánh giá 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 quy trình và chuyển đổ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 trọng tâm:

Tài liệu 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 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 chuyển đổi hệ thống, tài liệu quy trình phải được cập nhật tiếp.
Chuyển đổi hệ thống/di chuyển (GoBD Rz. 146–150): Khi chuyển đổi hệ thống, phải bảo đảm rằng dữ liệu của hệ thống cũ vẫn sẵn có, đọc được và có thể đánh giá bằng máy. Tài liệu quy trình phải ghi lại việc chuyển đổi.
Tính không thể thay đổi (GoBD Rz. 146): Sau khi ghi sổ, dữ liệu không được phép thay đổi. Các chỉnh sửa phải được thực hiện dưới dạng mục mới kèm lý do.

Hệ 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ệ quả	Cơ sở pháp lý	Mức độ/Rủi ro
Phụ phí chậm nộp	§ 152 AO	đến 25.000 EUR (từng trường hợp)
Ước tính căn cứ tính thuế	§ 162 AO	FA ướ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 chậm trễ	§ 146 Abs. 2c AO	2.500–250.000 EUR (khi thuê ngoài không có phê duyệt)
Đảo ngược nghĩa vụ chứng minh	§ 162 AO, § 90 AO	Doanh nhân phải bác bỏ ước tính - gần như không thể khi thiếu dữ liệu
Vi phạm hành chính	§ 379 AO	Tiền phạt đến 50.000 EUR (cố ý hoặc sơ suất)
Thủ tục tố tụng hình sự về thuế	§ 370 AO	Phạt tù đến 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 SV được chấp nhận không có phản đối - không có hệ 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 yêu cầu đánh giá bằng máy (§ 147 Abs. 6 AO), doanh nhân sẽ rơi vào tình thế khó giải thích. Việc lưu giữ tuân thủ GoBD không phải nghĩa vụ lý thuyết - nó trở thành hiện thực trong mỗi cuộc kiểm tra bên ngoài.

Vì sao Git giải quyết vấn đề

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

Yêu cầu AO/GoBD	Cách Git đáp ứng
"luôn sẵn có" (§ 146 Abs. 5)	`git clone` bất cứ lúc nào - không tài khoản đám mây, không giấy phép
"đọc được ngay lập tức" (§ 147 Abs. 2)	Tệp văn bản thuần (Markdown, JSON) - không cần phiên bản phần mềm
"có thể đánh giá 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ợ do doanh nhân chịu chi phí" (§ 147 Abs. 5)	Git là OSS, miễn phí - không 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 quy trình (GoBD Rz. 64–91)	Bản thân repo là tài liệu quy trình - `git log` cho thấy quy trình
Chuyển đổ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ử: định dạng XML là tài liệu gốc trong AO

Từ 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). Một hóa đơn điện tử chỉ tồn tại khi nó được phát hành, truyền và nhận trong 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 phạm vi này nữa - 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 đối với việc lưu giữ: Đối với một 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, không phải một PDF có thể được đính kèm hoặc một hình ảnh con người đọc được. BMF làm rõ (FAQ về hóa đơn điện tử, câu 13):

"Đối với 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ó còn nguyên vẹn ở dạng 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. Một bản hiển thị PDF chỉ là hiển thị hỗ trợ - nó không thay thế XML.
ZUGFeRD (lai: PDF + XML nhúng): Khi có sai lệch giữa phần XML và phần hình ảnh, từ năm 2025 phần có cấu trúc (XML) là phần quyết định (BMF FAQ câu 12a). Hình ảnh PDF không còn là phần dẫn đầu.

AO § 147 - Hóa đơn điện tử như chứng từ ghi sổ

Hóa đơn điện tử là chứng từ ghi sổ 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). Là tài liệu điện tử, chúng thuộc các yêu cầu AO/GoBD:

Luôn sẵn có (§ 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.
Có thể đánh giá bằng máy (§ 147 Abs. 6): XML theo định nghĩa là máy đọc được - lý tưởng cho § 147 Abs. 6 (truy cập dữ liệu khi kiểm tra bên ngoài).
Nguyên vẹn (§ 14b Abs. 1 UStG): Tệp XML không được phép thay đổi. Git đáp ứng điều đó thông qua tính không thể thay đổi sau commit (SHA-256-Hash).

Quy định toàn EU: EN 16931 và Chỉ thị 2014/55/EU

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

Chỉ thị 2014/55/EU - buộc các cơ quan mua sắm công phải tiếp 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 triển khai quốc gia của tiêu chuẩn EN này.
ViDA (VAT in the Digital Age) - việc mở rộng nghĩa vụ hóa đơn điện tử trên toàn EU theo kế hoạch và giới thiệu một hệ thống báo cáo dữ liệu giao dịch. Nghĩa vụ hóa đơn điện tử của Đức chuẩn bị cho ViDA.

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

Yêu cầu hóa đơn điện tử	Cách Git đáp ứng
XML là tài liệu gốc	Tệp XML được lưu không thay đổi trong repo - `git diff` không cho thấy thay đổi
Nguyên vẹn (§ 14b UStG)	SHA-256-Hash cho mỗi commit - mọi thay đổi sẽ hiển thị
Lưu giữ 8 năm (§ 147 Abs. 3)	Git-Bundle như kho lưu trữ self-contained - không cần tài khoản đám mây
Có thể đánh giá bằng máy (§ 147 Abs. 6)	XML theo định nghĩa là máy đọc được - `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 con người đọc được - cả hai 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) và 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ư vậy thời hạn chuyển tiếp 2025–2027 được bắc cầu mà không có gián đoạn phương tiện.

Các suy ra trực tiếp trong GitCover

Điểm đau	Khái niệm GitCover	Bài trong loạt
Tính xác thực 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 bằng chứng	Git-Repo với các hook được chuyên biệt hóa theo chức năng, sổ nền dưới dạng JSON	ED06, ED07
Thời hạn tùy ứng biến	`checks/FRISTEN_CHECK.md` + cảnh báo tự động	ED09
Thiếu xuất kiểm toán	GoBDExport (Z3), EuBPExport (eXTra), Evidence-Packages	ED08, ED36
Tài khoản lương bị tạm dừng, chi phí phát sinh thêm	Git-Bundles self-contained, không 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 lại, báo cáo	ED04, ED12, ED18, ED19
Không có OSS cho các trường hợp đặc biệt	GitCover bao phủ FZul/BSFZ, mục đích công ích, thời giờ làm việc, BEM	ED25–ED34

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

Vì sao Git là phương tiện nhật ký?

Git ban đầu 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 việc 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ê duyệt - Tags và Protected Branches bảo đảm rằng các mục nhật ký đã phê duyệt không bị thay đổi về sau (GoBD Rz. 146). Các chỉnh sửa được thực hiện dưới dạng 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ử có thể tái tạo.
Tính phi tập trung - Git-Bundles và GCEP (Advisory Locks) cho phép lưu trữ phân tán (Multi-Site, Off-Site-Backup) mà không có Single-Point-of-Failure trung tâm.

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

Loạt bài cho thấy các kỹ thuật sau giảm thiểu "hình ảnh không rõ ràng" về 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ố compliance máy đọc được (mức 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 lĩnh vực, thời hạn, tính hợp lý của nhóm đóng góp)
V7GUID Uniqueness - định danh duy nhất, ổn định theo thời gian, vượt ra ngoài tên tệp (dựa trên UUIDv7, có thể sắp xếp, không va chạm)
Git-Hooks (được chuyên biệt hóa theo chức năng/nội dung) - Pre-Commit kiểm tra tách biệt lĩnh vực, tính tuân thủ schema, trạng thái lỗi thời; Post-Commit tạo chỉ mục và cập nhật thời hạn
Các loại Code-Artefact và mục - JSON-Schema-First, nghĩa vụ Sidecar, chữ ký thời gian {YYMMDD HHmm}, tham chiếu chứng từ SHA-256

Nguyên tắc cốt lõi của khả năng truy vết theo thời gian: Thời điểm ghi nhận không phải một trường riêng, mà được neo trong chính uuidV7, như dấu thời gian 48 bit theo RFC 9562 §5.7. uuidV7 được tạo từ một mốc thời gian được chỉ định trước (không phải now()) qua GitCover Helper (UuidV7Gen), phần còn lại được điền ngẫu nhiên. Nhờ đó, thời điểm ghi nhận được liên kết bằng mật mã với danh tính của artifact và không thể thay đổi về sau. Một biểu diễn chuỗi datetime/date riêng 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 quan 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, phạm vi giá trị 0 … 2⁴⁸−1 (tầm với đến khoảng năm 10889). Đặc tả V7GUID được lưu trữ quy phạm trong work/OSS/TOP/.gitcover/specs/v7guid/; đơn đăng ký bằng sáng chế liên quan là DPMA Az. 10 2025 003 091.6.

Các routine helper (GitCover OSS Tools): Trong work/OSS/TOP/tools/UuidV7Gen/ có một helper OSS cung cấp hai thao tác trọng tâm:

gen - tạo một uuidV7 qua Guid.CreateVersion7() (.NET) (với mốc 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 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ừ khóa ngoại lai (ví dụ một mốc thời gian trong dữ liệu hoặc trong tên tệp) tạo ra một khóa uuidV7 hợp lệ - và đồng thời ghi lại 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 của việc dẫn xuất TenantId và thay vì thời gian hệ thống cũng có thể là một thời điểm được chỉ định rõ ràng (ví dụ từ mốc thời gian của chứng thư ELSTER, ngày của biên lai có TSE, v.v.) - việc diễn giải tuân theo tài liệu 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 trên registry .gitcover (cái gì/loại nào)

uuidV7 (Object ID) - danh tính của chính sidecar, được tạo với mốc 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 - danh tính của tài liệu gốc được phân loại — bằng chứng về tính nguyên bản, luôn luôn và ở mọi nơi (kể 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ư vậy không chỉ tài liệu được định danh duy nhất (thông qua SHA-256 của nó), mà cả chính hành vi phân loại - bao gồm thời điểm (trong uuidV7), ai đã phân loại và trong vai trò nào. Không có trường datetime riêng.

Đòn bẩy rủi ro - điều hôm nay rẻ (cheap) và ngày mai trở nên an toàn cho kiểm toán

Đòn bẩy rủi ro: Các sự kiện được ghi nhận hôm nay với chi phí tối thiểu (phút, qua 'tác nhân' chỉ trong khoảnh khắc) sẽ trở thành bằng chứng an toàn cho kiểm toán trong tương lai (giờ kiểm tra). Doanh nhân "nâng" một vị thế nghĩa vụ chứng minh - tuân thủ như đòn bẩy.

Hôm nay (rẻ, ~phút/giây)	Ngày mai (an toàn cho 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 tuân thủ GoBD (10 năm)	Vi phạm thời hạn lưu giữ
Trường `source` cho mỗi sự kiện	Nghĩa vụ chứng minh khi kiểm tra FA/SV	Giảm giá trị chứng cứ
Tệp kiểm tra thời hạn	Tránh bỏ lỡ thời hạn	Phụ phí chậm nộp § 152 AO
Thẻ lĩnh vực cho mỗi mục	Bảo vệ trạng thái mục đích công ích	Tước công nhận § 51 AO
Nhật ký chứng minh giờ FZul	Có thể đạt được chứng nhận BSFZ	Mất FZul (đến 1 triệu EUR)
Sidecar `.v7g.md` cho mỗi chứng từ	Có thể chứng minh tính xác thực của chứng từ	Tranh cãi về giá trị chứng cứ
JSON thời giờ làm việc cho mỗi ngày	Có thể chứng minh tuân thủ ArbZG	Tiền phạt § 22 ArbZG
Git-Bundle thay vì tài khoản đám mây	Lưu giữ không có chi phí nhà cung cấp dịch vụ	Mất quyền truy cập GoBD sau khi tạm dừng tài khoản
`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 hệ thống cũ không thể kích hoạt lại

Loạt bài này cho thấy gì

Loạt bài theo một doanh nhân hư cấu (E1), người điều hành một tổ chức KMU (placeholder, 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 thực tế, nhưng hoàn toàn được ẩn danh - mọi dữ liệu cá nhân, công ty, HRB, IBAN, mã số thuế đều được thay bằng placeholder.

Lưu ý DSGVO: Mọi liên hệ cá nhân/công ty trong loạt bài này là hư cấu hoặc đã được ẩn danh. Mọi sự tương đồng với các tổ chức thực tế là ngẫu nhiên và không có chủ ý.

Xem trước loạt bài

%%{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
ED14–ED20"] IV["Teil IV
Mitarbeiter & Lohn
+ Pflichten ab 1. Mitarbeiter
ED21–ED28"] 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
ED29–ED32"] VI["Teil VI
Harness-Anforderungen
ED33–ED36"] VII["Teil VII
Anhang
ED37–ED38"] 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
I	Cơ bản (bài này)	ED01–ED03
II	Quản trị doanh nghiệp: GoBD, AO, cơ quan thuế + nghĩa vụ từ đăng ký kinh doanh (lĩnh vực, VBG, khoản trọn gói)	ED05–ED11
III	Cơ quan & hiệp hội	ED14–ED20
IV	Nhân viên & lương + nghĩa vụ từ 1 nhân viên (thời giờ làm việc, MiLoG, nghỉ phép/ốm/BEM)	ED21–ED28
V	Thách thức đặc biệt (FZul/BSFZ, mục đích công ích)	ED29–ED32
VI	Yêu cầu harness	ED33–ED36
VII	Phụ lục (thuật ngữ, nguồn)	ED37–ED38

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

Có thể suy ra từ ED01:

ID	Yêu cầu	Ư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; thời gian trong `uuidV7` (RFC 9562 §5.7)	MUST
FA-1.3	`uuidV7` được tạo từ mốc thời gian được chỉ định trước (không phải `now()`) 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 đủ trong Harness-Anforderungen.md.

Nguồn

Chứng từ nguồn gốc cuộc kiểm tra SV (đã ẩn danh): E1/FY2025/BSFZ/Nachweise/00_BELEG_INVENTAR.md mục J
GoBD (BMF-Schreiben 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ử (tính đến 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/ (quy phạm)
DPMA Az. 10 2025 003 091.6 - đơn đăng ký bằng sáng chế V7GUID (yêu cầu chính 2, yêu cầu 5–8)
Công cụ OSS GitCover UuidV7Gen - work/OSS/TOP/tools/UuidV7Gen/ (các routine helper gen/decode)
DSGVO (nghĩa vụ ẩn danh khi công bố)

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

Vai trò	Vị trí	Mục đích
Primary / SSoT	git.gitcover.org/GCC	Kho lưu trữ chuẩn (ký GPG, được phiên bản hóa)
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 loại nguồn, mirror và community hub này phản ánh tình trạng hiện tại và có thể thay đổi. Vui lòng kiểm tra nguồn chuẩn tương ứng tại git.gitcover.org/GCC để biết tình trạng hiện tại. nguồn chuẩn trên gitcover.org cho tình trạng hiện tại.