ED01 - Động lực: Tại sao một doanh nhân 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 bức tranh không rõ ràng về các rủi ro sẽ xuất hiện trong tương lai. Những nghĩa vụ nào phát sinh khi nào? 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ệ khi nào về cuộc kiểm tra nào?

Thực tiễn hiện nay trong lĩnh vực KMU mang dấu ấn:

Thói quen ghi giấy tờ 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
Sự hỗn loạn PDF và email khi kiểm tra - hồ sơ được gom vộ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 chứng từ ở nơi khác) - không có chuỗi minh chứng liền mạch
Khoảng trống open-source 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, phi lợi nhuận) - ở đây gần như không có bất kỳ sự hỗ trợ tự do nào
Tắc nghẽn rủi ro - các nghĩa vụ hôm nay bị bỏ qua một cách cheap, cho đến khi ngày mai chúng trở nên đắt đỏ dưới dạng tiền phạt, phụ phí chậm trễ hoặc việc tước bỏ

%%{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 cheap
bị bỏ qua"] C --> D["Ngày mai đắt đỏ
Tiền phạt/Tước bỏ"] 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 mới cần an toàn kiểm toán - 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 các 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 các minh chứng an toàn kiểm toán trong tương lai. Compliance 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 nhờ các kỹ thuật GitCover (OSCAL, OPA, V7GUID, Git-Hooks), chứ không đợi đến khi kiểm tra viên gõ cửa.

Nguồn gốc: Cuộc kiểm tra SV là 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ề an sinh xã hội (SV) tại một UG siêu nhỏ (được ẩn danh ở đây 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 02/2024–03/2025. Cuộc kiểm tra đã bộc lộ những đ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 Kiểm tra SV ORG-V - Nguồn gốc của ý tưởng GitCover section 2024 - Kiểm tra được thông báo 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 ý kiến § 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 suy dẫn Q1 2025 : Thiết kế mô-đun AuditPrep Q2 2025 : Nghiên cứu & phát triển chuyên sâu Q3 2025 : Đăng ký V7GUID/GCEP tại DPMA

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 gom vội thành PDF/ZIP và gửi qua email	✅
02/2025	DRV chuyển giao kết quả kiểm tra (nghe ý kiến § 24 SGB X, Gesamtsummenblatt, 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 U1 đã trả thừa	+121 EUR
Truy đòi khoản đóng 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["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 chứng từ không rõ
PDF không có neo mật mã"] P3["Không có chuỗi minh chứng
Tài khoản lương/SV/hoàn trả nằm ở nhiều nơi"] P4["Thời hạn ad-hoc
quản lý thủ công trong lịch"] P5["Thiếu xuất 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 > 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 hoàn toàn qua email bằng các tệp PDF và ZIP. Các công cụ cho trường hợp siêu nhỏ này không hề 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ó được nhờ khả năng truy vết thủ công.
Không có chuỗi minh chứng liền mạch - tài khoản lương, tờ khai SV, minh chứng khoản đóng 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 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 kháng nghị đượ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); FA lẽ ra đã đòi một phương tiện dữ liệu Z3. Cả hai 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 vô ích duy trì một tài khoản cloud gây chi phí, khi lý do không còn tồn tại (người lao động đã nghỉ, không cần tính lương nữa)? 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ụ, và cuối cùng cao hơn khoản "hoàn trả" nhỏ bé ở 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ũ - để 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, tức là 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 dữ liệu. 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 cloud không sử dụng để tránh phát sinh chi phí. Chính sự căng thẳng này là một động lực cốt lõi của GitCover: Git-Bundles là self-contained - chúng không cần tài khoản cloud, 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 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 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ữ sổ sách, ghi chép và tài liệu ở dạng điện tử đúng quy cách 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 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 là trong suốt thời hạn lưu giữ, 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 hạch toán bằng điện tử phải bảo đảm trong suốt 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 có và đọc được ngay lập tức. Một tài khoản cloud bị tạm dừng, chỉ 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ó đượ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 thiết bị 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 cách 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 có, 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 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í

"Ai trình các tài liệu cần lưu giữ dưới dạng tái hiện trên một thiết bị 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ó thể đọ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ó thể đọ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 khi kiểm tra từ bên ngoài

"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, 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 để xử lý bằng máy theo các quy định của cơ quan."

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 cloud 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 trọng 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ó một 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 liên tục.
Thay đổi hệ thống/Chuyển đổi (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ũ vẫn 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 bị thay đổi. Các điều chỉnh 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 đa 25.000 EUR"] V --> K2["Ước tính
§ 162 AO
khi dữ liệu không sử dụng được"] 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 hành chính
§ 379 AO
Tiền phạt tới 50.000 EUR"] V --> K6["Thủ tục hình sự về thuế
§ 370 AO
khi cố ý gian lận thuế"] 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 đa 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 sử dụng được - 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ư bất khả thi khi thiếu dữ liệu
Vi phạm hành chính	§ 379 AO	Tiền phạt tới 50.000 EUR (cố ý hoặc do cẩu thả)
Thủ tục hình sự về thuế	§ 370 AO	Phạt tù tới 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 mà không có phản đối nào - 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 yêu cầu xử lý bằng máy (§ 147 Abs. 6 AO), doanh nhân đã lâm vào thế phải giải thích. Lưu giữ tuân thủ 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` thực hiện được bất cứ lúc nào - không cần tài khoản cloud, 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
"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 Obsoleszenz
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` cho thấy quy trình
Thay đổi hệ thống/Chuyển đổi (GoBD Rz. 146–150)	Git độc lập với phiên bản - `git clone` trên bất kỳ hệ thống nào

Hóa đơn điện tử (E-Rechnung): 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ử 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ỉ được coi là tồn tại khi nó được phát hành, truyền đi 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ừ 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 'đ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 then chốt cho 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, chứ không phải tệp PDF đính kèm (nếu có) hay 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):

"Đố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 giữ sao cho nó 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 giữ không thay đổi. Bản trực quan hóa PDF chỉ là 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ừ 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ử như chứng từ hạch toán

Các 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 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 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à máy đọc được - lý tưởng cho § 147 Abs. 6 (truy cập dữ liệu khi 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 pháp luật EU:

Chỉ thị 2014/55/EU - buộc các bên mua thuộc khu vực 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 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 toàn EU và đưa vào 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 là bướ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 rõ
Lưu giữ 8 năm (§ 147 Abs. 3)	Git-Bundle làm kho lưu trữ self-contained - không cần tài khoản cloud
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
Trực quan hóa (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ờ vậy, thời hạn chuyển tiếp 2025–2027 được bắc cầu mà không bị gián đoạn phương tiện.

Các suy dẫn 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õ	SHA-256 + V7GUID + Sidecar `.v7g.md` cho mỗi chứng từ	ED03, ED08
Không có chuỗi minh chứng	Git-Repo với các Hooks chuyên trách 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 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 cloud	ED08, ED09
Bản sao lưu cũ/phiên bản phần mềm cũ, vi phạm GoBD	Git-Repo làm phương tiện lưu giữ self-contained, `git clone` là đủ	ED08, ED09
Ai đứng sau công ty?	Transparenzregister: xác định, ghi nhận và báo cáo wB	ED04, ED12, ED17, ED18
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	ED25–ED34

Lưu ý - Nghĩa vụ của doanh nhân siêu nhỏ từ khi có nhân viên thứ 1: Chính các doanh nhân siêu nhỏ thường đã chịu những nghĩa vụ như vậy ngay từ nhân viên thứ 1 - ghi nhận 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ụ từ khi có 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à ảnh hưởng đến các cơ sở siêu nhỏ và nhỏ lần đầu tuyển nhân sự. GitCover cố ý nhắm đến ngưỡng này - bước chuyển từ doanh nhân solo sang người sử dụng lao động là thời điểm then chốt, khi các nghĩa vụ compliance 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 trong Phần II - chúng phát sinh mà không cần nhân viên.

Tại sao chọn 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 làm
phương tiện nhật ký"] G --> U["Không thể thay đổi
sau khi phê duyệt
(Tags, Protected Branches)"] G --> N["Truy vết được
Tác giả + dấu thời gian
+ toàn vẹn mật mã"] G --> D["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

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 điều chỉnh được thực hiện dưới dạng commit mới kèm đánh dấu Obsoleszenz.
Truy vết được - mỗi commit mang theo tác giả, dấu thời gian và toàn vẹn mật mã. Toàn bộ lịch sử có thể tái lập.
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ó điểm hỏng duy nhất tập trung (Single-Point-of-Failure).

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

Loạt bài 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
máy đọc được
Compliance-Statements"] CBD --> OPA["OPA/Rego
Policy as Code
kiểm tra tự động"] CBD --> V7["V7GUID Uniqueness
ID ổn định theo thời gian
duy nhất"] CBD --> HOOKS["Git-Hooks
chuyên trách theo chức năng
Pre/Post-Commit"] CBD --> ART["Code-Artefact-Typen
JSON-Schema-First
bắt buộc Sidecar"] OSCAL --> ZERT["Sẵn sàng chứng nhận
ISO 27001, AI Act, BSI GS++"] OPA --> POLICY["Sphären, thời hạn,
tính hợp lý nhóm đóng góp"] V7 --> UNIQ["Không trùng lặp,
sắp xếp được, độc lập tên tệp"] HOOKS --> CHECK["Schema, Sphären,
đã kiểm tra Obsoleszenz"] ART --> SIG["Chữ ký thời gian
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 Compliance-Statement máy đọc đượ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 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, sắp xếp được, không trùng lặp)
Git-Hooks (chuyên trách theo chức năng/theo nội dung) - Pre-Commit kiểm tra tách Sphären, tuân thủ schema, trạng thái Obsoleszenz; 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à mục nhập - JSON-Schema-First, bắt buộc 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 của khả năng truy vết thời gian: Thời điểm 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 từ một mốc thời gian đị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 điểm ghi nhận được liên kết mật mã với danh tính của artefact và không thể 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 dữ kiện - biểu diễn chuỗi cho DTO/HTMX là trách nhiệm của Harness.

Tham chiếu 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) - miligiâ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 Helper-Routine (GitCover OSS Tools): 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 mốc thời gian định trước khi cần, không chỉ now()) và trả về nhãn, 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 mốc thời gian trong dữ liệu hoặc trong tên tệp) - đồng thời ghi nhận lại các yêu cầu thời gian của GoBD (ghi nhận sát thời điểm, 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 định rõ ràng (ví dụ từ một mốc thời gian của chứng chỉ ELSTER, ngày trên 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 theo .gitcover Registry (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 đị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

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.

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

Risiko-Leverage: Các dữ kiện được ghi nhận hôm nay với chi phí tối thiểu (vài phút, qua 'Agenten' chỉ vài khoảnh khắc) sẽ trở thành các minh 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	Minh 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 dữ kiện	Gánh nặng chứng minh khi kiểm tra FA/SV	Hạ 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	Trạng thái phi lợi nhuận được bảo vệ	Tước bỏ theo § 51 AO
Nhật ký minh chứng giờ FZul	Có thể đạt 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 chứng từ chứng minh được	Phủ nhận giá trị chứng minh
JSON thời gian làm việc mỗi ngày	Tuân thủ ArbZG chứng minh được	Tiền phạt § 22 ArbZG
Git-Bundle thay cho tài khoản cloud	Lưu giữ không tốn chi phí nhà cung cấp dịch vụ	Mất truy cập GoBD sau khi tài khoản bị tạm dừng
`git clone` thay cho 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

Điều loạt bài này thể hiện

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

Lưu ý DSGVO: Mọi liên hệ đến cá nhân/công ty trong loạt bài này đều là hư cấu hoặc đã được ẩn danh. Bất kỳ điểm tương đồng nào với các tổ chức thực tế đều 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["Phần I
Kiến thức nền
ED01–ED04"] II["Phần II
GoBD, AO, Cơ quan thuế
+ Nghĩa vụ từ đăng ký kinh doanh
ED05–ED12"] III["Phần III
Cơ quan nhà nước & Hiệp hội
ED13–ED19"] IV["Phần IV
Nhân viên & Lương
+ Nghĩa vụ từ nhân viên thứ 1
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["Phần V
Thách thức đặc biệt
FZul/BSFZ, phi lợi nhuận
ED28–ED31"] VI["Phần VI
Yêu cầu Harness
ED32–ED35"] VII["Phần VII
Phụ lục
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 (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 (Sphären, VBG, Pauschalen)	ED05–ED11
III	Cơ quan nhà nước & Hiệp hội	ED13–ED19
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)	ED20–ED27
V	Thách thức đặc biệt (FZul/BSFZ, 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 dẫn 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ừ mốc thời gian đị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): 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ử (phiên bả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/ (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)
GitCover OSS Tool UuidV7Gen - work/OSS/TOP/tools/UuidV7Gen/ (các Helper-Routine gen/decode)
DSGVO (nghĩa vụ ẩn danh khi công bố)

Cấu trúc 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 hiện trạng 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 hiện trạng. nguồn chính tắc trên gitcover.org cho trạng thái hiện tại.