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 thành 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ẽ xuất hiện trong tương lai. Nghĩa vụ nào phát sinh vào lúc nào? Chứng từ nào phải được lưu trữ 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 cho đợt kiểm tra nào?

Thực tiễn hiện nay trong khu vực KMU (doanh nghiệp vừa và nhỏ) được định hình bởi:

Giấy tờ ghi chép rời rạc và các danh sách Excel cục bộ - không truy vết được, không an toàn kiểm toán
Hỗn loạn PDF và email trong các đợt kiểm tra - hồ sơ được ghép nối ad-hoc
Các giải pháp đảo rời rạc (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ở trong các nghĩa vụ đặc biệt (thời gian làm việc, chi phí công tác, các khoản trợ cấp, BEM, FZul/BSFZ, phi lợi nhuận) - ở đây hầu như không có sự hỗ trợ tự do nào
Ùn tắc 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ụ phí chậm trễ hoặc các quyết định tước quyền

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR A["Thành lập
Ngày 0"] --> B["Nghĩa vụ
không rõ ràng"] B --> C["Hôm nay bị bỏ qua
một cách cheap"] C --> D["Ngày mai đắt giá
Tiền phạt/Tước quyền"] D --> E["Rủi ro
hiện thực hóa"] 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 thực hiện chính xác điều đó: nó biến những dữ 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 bằng chứng an toàn kiểm toán trong tương lai. Tuân thủ trở thành đòn bẩy, 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 các kỹ thuật GitCover (OSCAL, OPA, V7GUID, Git-Hooks) giảm thiểu ngay từ đầu, chứ không đợi đến khi thanh tra viên bấm chuông.

Nguồn gốc: Cuộc kiểm tra SV như chất xúc tác thực tiễn

Ý tưởng GitCover không ra đời 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ề bảo hiểm xã hội (SV) tại một UG siêu nhỏ (ở đây được ẩn danh hóa là ORG-V, viết tắt của "tổ chức tiền thân") cho giai đoạn 2021–2023; diễn ra trong khoảng 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 tới 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 Kiểm tra SV ORG-V - Nguồn gốc của ý tưởng GitCover section 2024 - Đã thông báo kiểm tra Tháng 2 2024 : DRV thông báo BP theo § 28p SGB IV Tháng 12 2024 : Yêu cầu hồ sơ (tài khoản lương 2021–2023) Tháng 12 2024 : Gửi đi dưới dạng PDF/ZIP qua email section 2025 - Kiểm tra hoàn tất Tháng 2 2025 : DRV chuyển giao kết quả kiểm tra (nghe lý lẽ § 24 SGB X) Tháng 2 2025 : Chấp nhận không có phản đối Tháng 3 2025 : Kiểm tra SV hoàn tất : Ý tưởng GitCover ra đời section 2025 - Các dẫn xuất Q1 2025 : Thiết kế mô-đun AuditPrep Q2 2025 : F&E chuyên sâu Q3 2025 : Đăng ký DPMA V7GUID/GCEP

Chuyện 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ư kèm theo)	⏳
12/2024	Hồ sơ được ghép nối thành PDF/ZIP và gửi qua email	✅
02/2025	DRV chuyển giao kết quả kiểm tra (nghe lý lẽ § 24 SGB X, bảng tổng số, 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 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 đã nộp thừa	+121 EUR
Yêu cầu nộp bổ sung khoản đóng góp 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 bỏ ra	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["Không có văn phòng/fax/nhân viên
Kiểm tra chỉ qua email"] P2["Tính xác thực của chứng từ không rõ ràng
PDF không có neo mật mã"] P3["Không có chuỗi chứng cứ
Tài khoản lương/SV/hoàn trả nằm ở nhiều nơi khác nhau"] P4["Thời hạn ad-hoc
được quản lý thủ công trong lịch"] P5["Thiếu xuất dữ liệu kiểm toán
euBP/eXTra, Z3 chỉ với phần mềm chuyên dụng"] P6["Tài khoản lương bị tạm dừng
sau khi nhân viên nghỉ việc
Chi phí phát sinh > khoản hoàn trả"] P7["Bản sao lưu cũ
phiên bản phần mềm cũ
vi phạm yêu cầu GoBD"] P1 --> G["Ý tưởng GitCover
ra đời"] P2 --> G P3 --> G P4 --> G P5 --> G P6 --> G P7 --> G G --> S["Giải pháp GitCover
SHA-256+V7GUID, Hooks, kiểm tra thời hạn
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ó hoạt động văn phòng, không fax, không 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 email 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 email không có neo mật mã. Ai đã thay đổi cái gì vào lúc nào? Giá trị chứng minh 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, thông báo SV, giấy xác nhận đó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àm rõ đều đòi hỏi phải tìm kiếm lại.
Quản lý thời hạn ad-hoc - thời hạn nghe lý lẽ, 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ô ích một cách tốn kém khi lý do không còn tồn tại (người lao động đã 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 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 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 vi phạm quy định đối với yêu cầu GoBD, đó là phải bảo đảm về mặt kỹ thuật rằng trong thời gian lưu trữ 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 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à độ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 với 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 trữ đượ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 yêu cầu GoBD" được đề cập ở điểm 7 có cơ sở pháp lý rõ ràng - trong Luật Thuế (Abgabenordnung, AO) và trong GoBD (các nguyên tắc về việc dẫn sổ sách, ghi chép và lưu trữ chứng từ đúng quy định ở 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 có trong thời hạn lưu trữ

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

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

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

"Ngoại trừ báo cáo tài chính năm [...], các tài liệu được liệt kê trong khoản 1 cũng có thể được lưu trữ 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 trữ luôn sẵn có, có thể được đọc ra ngay lập tức và xử lý được bằng máy."

Một lần nữa: "luôn sẵn có", "đọ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ợ do người nộp thuế chịu chi phí

"Người nộp các tài liệu cần lưu trữ 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 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 này 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 tế 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 từ bên ngoài

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

Trong một cuộc kiểm tra từ bên ngoài, 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 trung tâm:

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/migration (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 sẵn có, đọ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 mục mới kèm lý do.

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["Vi phạm
AO § 146/147 + GoBD"] V --> K1["Phụ phí chậm trễ
§ 152 AO
tới 25.000 EUR"] V --> K2["Ước tính
§ 162 AO
khi dữ liệu không thể sử dụng"] V --> K3["Tiền phạt chậm trễ
§ 146 Abs. 2c AO
2.500–250.000 EUR"] V --> K4["Đảo ngược gánh nặng chứng minh
FA ước tính, doanh nhân
phải bác bỏ"] V --> K5["Vi phạm trật tự hành chính
§ 379 AO
tiền phạt tới 50.000 EUR"] V --> K6["Quy trình hình sự về thuế
§ 370 AO
khi cố ý gian lận"] 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ụ phí chậm trễ	§ 152 AO	tới 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 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
Vi phạm trật tự hành chính	§ 379 AO	Tiền phạt tới 50.000 EUR (cố ý hoặc do sơ suất)
Quy trình hình sự về thuế	§ 370 AO	Phạt tù tới 5 năm (khi cố ý trốn thuế)

Đá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 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. Lưu trữ 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 từ bên ngoài.

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 có" (§ 146 Abs. 5)	`git clone` khả dụng mọi lúc - 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)	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ợ do doanh nhân chịu chi phí" (§ 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 (obsolescence)
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/migration (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

Từ ngày 1 tháng 1 năm 2025, hóa đơn điện tử trở thành 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ỉ được coi là tồn tại khi nó được phát hành, 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 thuần không còn thuộc phạm vi 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["Hóa đơn giấy
trước 2025"] --> U["Giai đoạn chuyển tiếp
2025–2027"] PDF["PDF qua email
trước 2025 được coi là 'điện tử'"] --> U U --> E["Hóa đơn điện tử
bắt buộc từ 2025
có cấu trúc, máy đọc được"] E --> X["XRechnung
dựa trên XML
EN 16931"] E --> Z["ZUGFeRD
lai: PDF + XML
từ 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 trữ: Đố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, chứ không phải tệp PDF đính kèm (nếu có) hay 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):

"Đối 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 trữ sao cho nguyên vẹn ở hình thức ban đầu."

Điều này 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 trữ không thay đổi. Bản hiển thị PDF chỉ là một hiển thị hỗ trợ - nó không thay thế được 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ừ kế toán

Hóa đơn điện tử là chứng từ kế toán theo nghĩa của § 147 Abs. 1 Nr. 4 AO và do đó phải được lưu trữ 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 có (§ 147 Abs. 2): Tệp XML phải có thể truy cập trong suốt toàn bộ thời hạn lưu trữ.
Đọ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à máy đọc được - lý tưởng cho § 147 Abs. 6 (truy cập dữ liệu trong kiểm tra từ bên ngoài).
Nguyên vẹn (§ 14b Abs. 1 UStG): Tệp XML không được bị 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 trên phạm vi 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 bên thuê 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 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 toàn EU 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.

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ẽ hiển thị
Lưu trữ 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
Xử lý được 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ị trực quan (BMF FAQ 12a)	XML + sidecar Markdown đọ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 trữ 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 repo Git có thể lưu trữ 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 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, ED06
Không có chuỗi chứng cứ	Repo Git với các hook chuyên biệt theo chức năng, Grundbuch dưới dạng JSON	ED04, ED05
Thời hạn ad-hoc	`checks/FRISTEN_CHECK.md` + cảnh báo tự động	ED07
Thiếu xuất dữ liệu kiểm toán	GoBDExport (Z3), EuBPExport (eXTra), Evidence-Packages	ED06, ED25
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	ED06, ED07
Bản sao lưu cũ/phiên bản phần mềm cũ, vi phạm GoBD	Repo Git như phương tiện lưu trữ self-contained, `git clone` là đủ	ED06, ED07
Không có OSS cho các trường hợp đặc biệt	GitCover bao phủ FZul/BSFZ, phi lợi nhuận, thời gian làm việc, BEM	ED15–ED24

Lưu ý - Nghĩa vụ của doanh nhân siêu nhỏ từ nhân viên thứ 1: Thường chính các doanh nhân siêu nhỏ đã chịu những nghĩa vụ như vậy ngay 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ý bảo hiểm xã hội (SGB IV). Do đó, các nghĩa vụ từ nhân viên thứ 1 được đề cập ở 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 nhân sự. GitCover cố ý hướng tới ngưỡng này - bước chuyển từ doanh nhân độc thân sang chủ sử dụng lao động là thời điểm tới hạn, khi các nghĩa vụ tuân thủ tăng vọt. Các nghĩa vụ phát sinh từ đăng ký kinh doanh (phân loại Sphären, miễn trừ VBG, Pauschalen) đã được đề cập ở 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ý?

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 Compliance:

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR G["Git như
phương tiện nhật ký"] G --> U["Tính không thể thay đổi
sau khi phê duyệt
(Tags, Protected Branches)"] G --> N["Khả năng truy vết
Tác giả + dấu thời gian
+ tính toàn vẹn mật mã"] G --> D["Tính phi tập trung
Git-Bundles + GCEP
Multi-Site, Off-Site"] U --> GoBD["GoBD Rz. 146
tuân thủ"] N --> Audit["Audit-Ready
tái lập được"] D --> Backup["Không có SPOF
phân tán"] 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ị sửa đổi về sau (GoBD Rz. 146). Các chỉnh sửa được thực hiện dưới dạng commit mới kèm đánh dấu lỗi thời (obsolescence).
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 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ó điểm hỏng duy nhất tập trung (Single-Point-of-Failure).

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

Chuỗi bài viết cho thấy các kỹ thuật sau 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
các tuyên bố Compliance
máy đọc được"] CBD --> OPA["OPA/Rego
Policy as Code
kiểm tra tự động"] CBD --> V7["V7GUID Uniqueness
ID duy nhất
ổn định theo thời gian"] CBD --> HOOKS["Git-Hooks
chuyên biệt theo chức năng
Pre/Post-Commit"] CBD --> ART["Các loại artefact mã nguồn
JSON-Schema-First
bắt buộc sidecar"] OSCAL --> ZERT["Độ chín chứng nhận
ISO 27001, AI Act, BSI GS++"] OPA --> POLICY["Sphären, thời hạn,
tính hợp lý của nhóm đóng góp"] V7 --> UNIQ["Không xung đột,
sắp xếp được, độc lập tên tệp"] HOOKS --> CHECK["Schema, Sphären,
đã kiểm tra obsolescence"] ART --> SIG["Chữ ký temporal
tham chiếu chứng từ SHA-256"] 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 (độ chín 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 duy nhất, ổn định theo thời gian, vượt ra ngoài tên tệp (dựa trên UUIDv7, sắp xếp được, 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, tính tuân thủ schema, trạng thái obsolescence; Post-Commit tạo các chỉ mục và cập nhật thời hạn
Các loại artefact mã nguồn và các mục - JSON-Schema-First, bắt buộc sidecar, chữ ký temporal {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 temporal: 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ờ vậy, thời gian ghi nhận được liên kết mật mã với danh tính của artefact 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 lưu trong các dữ 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 tới 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 thủ tục Helper (công cụ OSS GitCover): Tại 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ề nhãn (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ề 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 khóa ngoài (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 temporal 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 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 khóa tổng hợp (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 dấu thời gian được chỉ định/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

Như vậy, không chỉ tài liệu được định danh duy nhất, 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.

Đòn bẩy rủi ro - cái gì hôm nay giá rẻ (cheap) và ngày mai trở nên an toàn kiểm toán

Đòn bẩy rủi ro: Những dữ kiện được ghi nhận hôm nay với chi phí tối thiểu (vài phút, qua 'Agent' chỉ vài khoảnh khắc) sẽ trở thành 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 - tuân thủ 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 trữ
Trường `source` cho mỗi dữ kiện	Gánh nặng chứng minh trong kiểm tra FA/SV	Hạ cấp giá trị chứng minh
Tệp kiểm tra thời hạn	Tránh bỏ lỡ thời hạn	Phụ phí chậm trễ § 152 AO
Tag Sphären cho mỗi mục	Bảo vệ được tư cách phi lợi nhuận	Tước tư cách § 51 AO
Nhật ký chứng minh giờ FZul	Có thể đạt được chứng nhận BSFZ	Mất FZul (tới 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	Phủ nhận giá trị chứng minh
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 trữ không tốn chi phí nhà cung cấp dịch vụ	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 trữ 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

Chuỗi này trình bà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ỗ, không ràng buộc hình thức pháp lý) và ghi nhật ký của mình trong một repo Git. 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 này đều là hư cấu hoặc đã được ẩn danh hóa. Bất kỳ điểm tương đồng nào với các tổ chức có thật đều 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["Phần I
Nền tảng
ED01–ED03"] II["Phần II
GoBD, AO, Cơ quan thuế
+ Nghĩa vụ từ đăng ký kinh doanh
ED04–ED10"] III["Phần III
Cơ quan nhà nước & Hiệp hội
ED11–ED14"] IV["Phần IV
Nhân viên & Lương
+ Nghĩa vụ từ nhân viên thứ 1
ED15–ED22"] 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["Phần V
Những thách thức đặc biệt
FZul/BSFZ, phi lợi nhuận
ED23–ED26"] VI["Phần VI
Yêu cầu Harness
ED27–ED30"] VII["Phần VII
Phụ lục
ED31–ED32"] 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	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ụ từ đăng ký kinh doanh (Sphären, VBG, Pauschalen)	ED04–ED10
III	Cơ quan nhà nước & Hiệp hội	ED11–ED14
IV	Nhân viên & Lương + nghĩa vụ từ nhân viên thứ 1 (thời gian làm việc, MiLoG, nghỉ phép/ốm đau/BEM)	ED15–ED22
V	Những thách thức đặc biệt (FZul/BSFZ, phi lợi nhuận)	ED23–ED26
VI	Yêu cầu Harness	ED27–ED30
VII	Phụ lục (Bảng thuật ngữ, Nguồn)	ED31–ED32

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	Khóa tổng hợp `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()`) qua Helper	MUST
FA-2.1	SHA-256 làm ID chứng từ	MUST
FA-2.2	Bắt buộc 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 cuộc kiểm tra SV (đã ẩ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 trữ)
BMF-FAQ về hóa đơn điện tử (tình trạng 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 chính 2, các yêu cầu 5–8)
Công cụ OSS GitCover UuidV7Gen - work/OSS/TOP/tools/UuidV7Gen/ (các thủ tục Helper 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 tới Codeberg

Lưu ý: Việc phân bổ 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 chính tắc tương ứng tại git.gitcover.org/GCC để nắm tình trạng mới nhất. nguồn chính tắc trên gitcover.org cho trạng thái hiện tại.