ED01 - Động lực: Vì sao một doanh nhân lưu 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ề các rủi ro sẽ phát sinh trong tương lai. Nghĩa vụ nào phát sinh khi nào? Chứng từ nào phải lưu trữ trong bao lâu? Hạn nào có nguy cơ bị bỏ lỡ? Cơ quan nào sẽ thông báo kiểm tra khi nào?

Thực hành hiện nay trong khu vực SME được đặc trưng bởi:

• Sổ sách lộn xộn và danh sách Excel cục bộ - không truy vết được, không đảm bảo kiểm toán
• Hỗn loạn PDF và email trong các đợt kiểm tra - tài liệu được gom lại vội vãng
• Giải pháp rời rạc (phần mềm lương ở đây, kế toán ở kia, kho chứng từ ở nơi khác) - không có chuỗi chứng minh liên tục
• Khoảng trống nguồn mở đối với các nghĩa vụ đặc thù (FZul/BSFZ, phi lợi nhuận, thời gian làm việc, BEM) - ở đây gần như không có hỗ trợ tự do nào
• Tích tụ rủi ro - nghĩa vụ bị bỏ qua với chi phí thấp hôm nay, đến mai trở nên đắt đỏ dưới dạng phạt tiền, phụ cấp chậm trễ hoặc tước quyền

Luận điểm cốt lõi

Không chỉ tài liệu phải đảm bảo kiểm toán - mà quyết định, hạn và tham chiếu chứng từ cũng phải truy vết được, tái lập được và có thể kiểm toán. 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 cheap (chi phí thấp) (một mục JSON với V7GUID + tham chiếu chứng từ SHA-256) thành chứng từ đảm bảo kiểm toán trong tương lai. Tuân thủ trở thành đòn bẩy, chứ không phải phanh.

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

Sự hình thành: Cuộc kiểm toán 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ừ kinh nghiệm thực tiễn cụ thể: gần đây nhất là một cuộc kiểm toán hoạt động SV tại một UG siêu nhỏ (ở đây ẩn danh dưới tên ORG-V - "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 toán bộc lộ điểm đau mà các kỹ thuật GitCover giải quyết.

Timeline kiểm toán SV

Chuyện gì đã xảy ra?

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

Điểm đau - điều kiểm toán bộc lộ

1. Không có văn phòng, không có fax, không có nhân viên - và vẫn phải xử lý một cuộc kiểm toán hoạt động 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 siêu nhỏ này.
2. Tính xác thực chứng từ không rõ - PDF qua email không có neo mật mã. Ai đã thay đổi gì, khi nào? Giá trị chứng minh chỉ đạt được qua truy vết thủ công.
3. Không có chuỗi chứng minh liên tục - sổ lương, thông báo SV, chứng từ đóng góp và biên lai hoàn trả nằm rải rác ở nhiều nơi, không có tham chiếu chéo. Mỗi câu hỏi ngược lại đều đòi hỏi tìm kiếm lại.
4. Quản lý hạn ad-hoc - hạn nghe theo, hạn hoàn trả, hạn khiếu nại được duy trì thủ công trong lịch. Không có cảnh báo khi hạn sắp trôi qua.
5. 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 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 xử lý thủ công.
6. Nhân viên nghỉ việc → tài khoản lương bị tạm dừng - sau khi nhân viên thời điểm đó 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 giữ một tài khoản đám mây gây chi phí vô ích khi lý do không còn (người lao động đã nghỉ, không cần tính lương nữa)? Việc gom gói tài liệu cho kiểm toán sau đó lại đòi hỏi chi phí phụ thêm tại nhà cung cấp dịch vụ, cuối cùng cao hơn khoản "hoàn trả" nhỏ ở cuối kiểm toán.
7. 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ũ - để truy cập lại sổ lương 2021–2023, 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à vi phạm quy định GoBD, vốn cũng yêu cầu đảm bảo về mặt kỹ thuật rằng trong suốt thời gian lưu trữ dài (10 năm) luôn có thể truy cập. Trên thực tế, nghĩa vụ này xung đột với áp lực kinh tế không duy trì các tài khoản đám mây không sử dụng gây chi phí. Chính căng thẳng này là động lực cốt lõi của GitCover: Git-Bundle là self-contained - 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 phụ thuộc phiên bản phần mềm. Một git clone là đủ, và nghĩa vụ 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 GoBD" được đề cập ở điểm 7 có cơ sở pháp lý rõ ràng - trong Abgabenordnung (AO) và trong GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff, thông tư BMF).

AO § 146 Abs. 5 - Khả dụng trong thời gian lưu trữ

"Bei der Führung der Bücher und der sonst erforderlichen Aufzeichnungen auf Datenträgern muss insbesondere sichergestellt sein, dass während der Dauer der Aufbewahrungsfrist die Daten jederzeit verfügbar sind und unverzüglich lesbar gemacht werden können."

Đây là quy định cốt lõi: ai ghi sổ điện tử phải đảm bảo trong suốt thời gian lưu trữ (10 năm cho sổ sách/ghi chép, 8 năm cho 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ỉ kích hoạt lại khi trả thêm phí, 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 độ trễ.

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

"Mit Ausnahme der Jahresabschlüsse [...] können die in Absatz 1 aufgeführten Unterlagen auch als Wiedergabe auf einem Bildträger oder auf anderen Datenträgern aufbewahrt werden, wenn dies den Grundsätzen ordnungsmäßiger Buchführung entspricht und sichergestellt ist, dass die Wiedergabe oder die Daten [...] während der Dauer der Aufbewahrungsfrist jederzeit verfügbar sind, unverzüglich lesbar gemacht und maschinell ausgewertet werden können."

Lặp lại: "luôn sẵn có", "đọc được ngay lập tức", "có thể xử lý bằng máy". Một phiên bản phần mềm cũ cần 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ế chi trả

"Wer aufzubewahrende Unterlagen in der Form einer Wiedergabe auf einem Bildträger oder auf anderen Datenträgern vorlegt, ist verpflichtet, auf seine Kosten diejenigen Hilfsmittel zur Verfügung zu stellen, die erforderlich sind, um die Unterlagen lesbar zu machen."

Tức 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ự cung cấp phương tiện hỗ trợ (phần mềm, giấy phép, phần cứng) để đọc dữ liệu. Đó chính là vấn đề thực tiễn trong trường hợp hình thành: 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.

AO § 147 Abs. 6 - Truy cập dữ liệu trong kiểm tra tại chỗ

"Sind die Unterlagen nach Absatz 1 mit Hilfe eines Datenverarbeitungssystems erstellt worden, kann die Finanzbehörde im Rahmen einer Außenprüfung [...] verlangen, dass die Daten nach ihren Vorgaben maschinell ausgewertet zur Verfügung gestellt werden."

Trong kiểm tra tại chỗ, doanh nhân phải cung cấp dữ liệu có thể xử lý bằng máy - không phải 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ỉ xuất được PDF là không đủ.

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

GoBD cụ thể hóa các quy định AO cho 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 ghi sổ đ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, biện pháp tổ chức và kiểm soát nội bộ. Khi chuyển đổi hệ thống, tài liệu hóa quy trình phải được tiếp tục cập nhật.
• Chuyển đổi/hồi chuyển hệ thống (GoBD Rz. 146–150): Khi chuyển đổi hệ thống, phải đảm bảo dữ liệu của hệ thống cũ vẫn sẵn có, đọc được và xử lý bằng máy được. Tài liệu hóa quy trình phải ghi nhận việc chuyển đổi.
• Tính không thay đổi (GoBD Rz. 146): Sau khi ghi sổ, dữ liệu không được thay đổi. Sửa chữa phải 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

Đánh giá thực tiễn: Trong trường hợp hình thành, kiểm toán SV được chấp nhận không có khiếu 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ạng PDF mà kiên quyết yêu cầu xử lý bằng máy (§ 147 Abs. 6 AO), doanh nhân sẽ lúng túng. Lưu trữ theo GoBD không phải nghĩa vụ lý thuyết - nó được áp dụng thực tế trong mọi kiểm tra tại chỗ.

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

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

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ử trở thành bắt buộc cho giao dịch giữa các doanh nghiệp trong nước (§ 14 UStG, Luật Cơ hội Tăng trưởng). Một hóa đơn điện tử chỉ được coi là có khi được lập, truyền và nhận ở đị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ệp PDF đơn giản không còn thuộc phạm vi này - từ 2025 nó là "hóa đơn khác".

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

Điểm quyết định cho lưu trữ: trong 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 AO, chứ không phải một tệp PDF kèm theo hay một hình ảnh đọc được bởi con người. BMF làm rõ (FAQ về hóa đơn điện tử, câu 13):

"Bei einer E-Rechnung ist zumindest deren strukturierter Teil so aufzubewahren, dass er unversehrt in seiner ursprünglichen Form vorliegt."

Tức là:

• XRechnung (dựa trên XML, EN 16931): Tệp XML là tài liệu gốc. Phải lưu trữ không thay đổi. PDF hiển thị chỉ là phụ - 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ừ 2025 phần có cấu trúc (XML) là quyết định (BMF FAQ câu 12a). PDF không còn dẫn dắt.

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

Hóa đơn điện tử là chứng từ ghi sổ theo § 147 Abs. 1 Nr. 4 AO và do đó phải lưu trữ tám năm (§ 147 Abs. 3 AO). Là tài liệu điện tử, áp dụng các yêu cầu AO/GoBD:

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

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 - bắt buộc bên mua công phải nhận và xử lý hóa đơn điện tử (B2G).
• EN 16931 (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à triển khai quốc gia của 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ử toàn EU và giới thiệu 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ử

Mẹo thực tiễn: Một repo Git có thể lưu song song hóa đơn điện tử (XML) và hóa đơn khác (PDF) - với phân tách rõ qua 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ệ (schema XRechnung/ZUGFeRD) không. Nhờ đó giai đoạn chuyển tiếp 2025–2027 được vượt qua mà không có đứt gãy phương tiện.

Dẫn xuất trực tiếp trong GitCover

Lưu ý - Nghĩa vụ của doanh nhân siêu nhỏ từ nhân viên đầu tiên: Thường ngay cả doanh nhân siêu nhỏ đã chịu các nghĩa vụ như vậy từ nhân viên đầu tiên - ghi nhận thời gian làm việc (ArbZG), tài liệu hóa lương tối thiểu (MiLoG), phép ốm/BEM (BUrlG/EFZG/SGB IX), đăng ký bảo hiểm xã hội (SGB IV). Các nghĩa vụ từ nhân viên đầu tiên được xử lý trong Phần IV không phải chủ đề đặc thù của doanh nghiệp lớn, mà đúng hơn áp dụng cho các cơ sở siêu nhỏ và nhỏ khi lần đầu tuyển nhân sự. GitCover nhắm đến ngưỡng này một cách có ý thức

• chuyển đổi từ doanh nhân độc thân sang người sử dụng lao động là thời điểm tới hạn, khi nghĩa vụ tuân thủ tăng vọt. Nghĩa vụ từ khi đăng ký kinh doanh (phân loại lĩnh vực, miễn trừ VBG, khoản cố định) đã được xử lý trong Phần II
• chúng phát sinh không cần nhân viên.

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

Git vốn là hệ thống kiểm soát phiên bản - nhưng nó mang ba đặc tính khiến nó by Design phù hợp với tuân thủ:

1. Tính không thay đổi sau khi phê duyệt - Tags và Protected Branches đảm bảo rằng các mục nhật ký đã phê duyệt không bị thay đổi sau đó (GoBD Rz. 146). Sửa chữa được thực hiện dưới dạng commit mới với đánh dấu lỗi thời.
2. Khả năng truy vết - mỗi commit mang theo 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.
3. Tính phân tán - Git-Bundle và GCEP (Advisory Locks) cho phép lưu trữ phân tán (Multi-Site, sao lưu Off-Site) không có Single-Point-of-Failure trung tâm.

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

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

• OSCAL - tuyên bố tuân thủ đọc được bằng máy (độ sẵn sàng chứng nhận cho ISO 27001, AI Act, BSI GS++)
• OPA/Rego - Policy as Code, kiểm tra chính sách tự động (tách lĩnh vực, hạn, tính hợp lý của nhóm đóng góp)
• Tính duy nhất V7GUID - đị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 xung đột)
• Git-Hooks (chuyên dụng theo chức năng/chủ đề) - Pre-Commit kiểm tra tách lĩnh vực, tuân thủ schema, trạng thái lỗi thời; Post-Commit tạo chỉ mục và cập nhật hạn
• Loại artefact mã và mục - JSON-Schema-First, bắt buộc sidecar, chữ ký thời gian {YYMMDD HHmm}, tham chiếu chứng từ SHA-256

Nguyên lý cốt lõi của truy vết thời gian: Thời điểm ghi nhận không phải là một trường riêng, mà được neo trong chính uuidV7, dưới dạng dấu thời gian 48-bit theo RFC 9562 §5.7. uuidV7 được sinh từ một dấu thời gian cho trước (không phải now()) qua helper GitCover (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 mật mã với định danh của artefact và không thể thay đổi sau đó. Một biểu diễn datetime/date dạng chuỗi riêng là dư thừa và không được lưu trong các sự 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 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 đến khoảng năm 10889). Đặc tả V7GUID được lưu chuẩn tắc tại work/OSS/TOP/.gitcover/specs/v7guid/; bằng sáng chế liên quan là DPMA Az. 10 2025 003 091.6.

Helper-Routinen (GitCover OSS Tools): Tại work/OSS/TOP/tools/UuidV7Gen/ có một helper OSS cung cấp hai thao tác trung tâm:

• gen - tạo một uuidV7 qua Guid.CreateVersion7() (.NET) với dấu thời gian cho trước (không phải 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ề dưới dạng dấu thời gian ISO-8601.

Các helper này quyết định để tạo một khóa uuidV7 hợp lệ từ khóa ngoại (ví dụ một dấu thời gian trong dữ liệu hoặc trong tên tệp) - và đồng thời tài liệu hóa yêu cầu thời gian của GoBD (ghi nhận sát thời điểm, truy vết thời điểm ghi nhận). Giá trị 48-bit là yếu tố duy nhất của việc suy ra TenantId và có thể là một thời điểm cho trước rõ ràng thay vì thời gian hệ thống (ví dụ ngày thành lập của một tenant) - cách diễn giải theo tài liệu hóa quy trình.

Nguyên lý Sidecar (.v7g.md): Mỗi sidecar mang một khóa tổ hợp V7GUID:uuidV7:

• V7GUID (Class Identifier) - phân loại sidecar theo registry .gitcover (cái gì/loại nào)
• uuidV7 (Object ID) - định danh của chính sidecar, sinh với dấu thời gian cho trước (khi nào được phân loại?), 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ờ đó không chỉ tài liệu được định danh duy nhất, mà cả hành vi phân loại tự thân - bao gồm thời điểm (trong uuidV7), ai phân loại và theo vai trò nào. Không có trường datetime riêng.

Đòn bẩy rủi ro - điều rẻ (cheap) hôm nay, mai trở thành đảm bảo kiểm toán

Đòn bẩy rủi ro: Sự kiện ghi nhận hôm nay với chi phí tối thiểu (phút) trở thành chứng từ đảm bảo kiểm toán trong tương lai (giờ kiểm toán). Doanh nhân "nâng" một vị thế nghĩa vụ chứng minh - tuân thủ như một đòn bẩy.

Serie này cho thấy gì

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

Lưu ý DSGVO: Mọi liên hệ cá nhân/công ty trong serie này đều hư cấu hoặc ẩn danh. Mọi giống nhau với tổ chức thực là ngẫu nhiên và không có chủ đích.

Xem trước serie

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

Dẫn xuất từ ED01:

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

Nguồn

• Chứng từ hình thành kiểm toán SV (ẩn danh): AFJD/FY2025/BSFZ/Nachweise/00_BELEG_INVENTAR.md mục J
• GoBD (thông tư 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 toán hoạt động)
• 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 (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 - bằng sáng chế V7GUID (yêu cầu chính 2, yêu cầu 5–8)
• GitCover OSS Tool UuidV7Gen - work/OSS/TOP/tools/UuidV7Gen/ (helper gen/decode)
• DSGVO (nghĩa vụ ẩn danh khi công bố)

Topology nguồn và liên kết CDN

Lưu ý: Việc phân bổ nguồn, mirror và community-hub này phản ánh trạng thái hiện tại và có thể thay đổi. Vui lòng kiểm tra nguồn chuẩn tắc tương ứng tại gitcover.org cho trạng thái hiện hành.