ED01 - Động lực: Vì 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 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 đượ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 sẽ liên hệ vào lúc nào để thực hiện cuộc kiểm tra nào?

Thực tiễn hiện nay trong khu 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 đủ độ tin cậy để 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 thời điểm
• Giải pháp ốc đảo (phần mềm lương ở đây, kế toán ở đó, kho chứng từ ở nơi khác) - không có chuỗi bằng chứng xuyên suốt
• Khoảng trống mã nguồn mở đối với các nghĩa vụ đặc biệt (thời gian làm việc, chi phí đi lại, phụ cấp, BEM, FZul/BSFZ, tư cách công ích) - gần như không có hỗ trợ miễn phí nào ở đây
• Rủi ro tích tụ - các nghĩa vụ hôm nay bị phớt lờ với chi phí thấp, 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

Tuyên bố cốt lõi

Không chỉ tài liệu phải có độ tin cậy 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 lập 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 với chi phí cheap (rẻ) (một mục JSON với V7GUID + tham chiếu chứng từ SHA-256) thành bằng chứng có độ tin cậy 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: “Bức tranh không rõ ràng” về các rủi ro trong 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 người kiểm tra gõ cửa.

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

Nhật ký không phải là sổ ghi chú riêng và cũng không phải lịch thời gian làm việc được ghi chép về sau. Nó là SSoT về thời gian của công việc: lịch trình 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 quy trình nào. Nhờ đó, cùng một bằng chứng công việc có thể phục vụ nhiều mục đích khác nhau mà không cần 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: nguyên nhân phát sinh từ hoạt động kinh doanh và các phần riêng tư/kinh doanh vẫn có thể truy vết.
• USt: khoảng thời gian thực hiện, việc thực thi hợp đồng và liên kết hóa đơn có thể được nối kết.
• GoBD/AO: chứng từ, quyết định, phê duyệt và thay đổi tạo thành một chuỗi hồi tố/tiến triển.
• Rủi ro và tính di động: hoạt động không phụ thuộc vào trí nhớ của một cá nhân hoặc vào cổng của nhà cung cấp; các sự kiện nằm trong các tạo tác Git mở, có phiên bản.

Quy tắc rất đơn giản: Nhật ký mô tả lịch trình; các repository lưu giữ bằng chứng. Một agent chỉ được suy ra từ nhật ký những gì mà các Ur-Docs và sidecar được liên kết chứa đựng. Như vậy, tuân thủ không được xem là công việc bổ sung về sau, mà được thực hiện 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 sinh ra trong tháp ngà, mà từ các 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 SV tại một UG siêu nhỏ (ở đâ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 khoảng 02/2024–03/2025. Cuộc kiểm tra đã bộc lộ các điểm đau mà kỹ thuật GitCover giải quyết.

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

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

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

Các điểm đau - những gì cuộc kiểm tra bộc lộ

1. Không có văn phòng, không fax, không nhân viên - vậy mà 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 siêu nhỏ này.
2. Tính xác thực của chứng từ không rõ ràng - PDF qua email không có neo mật mã. Ai đã thay đổi điều gì vào khi nào? Giá trị chứng cứ chỉ được đảm bảo thông qua khả năng truy vết thủ công.
3. Không có chuỗi bằng chứng xuyên suốt - tài khoản lương, báo cá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 lần hỏi lại đều phải tìm kiếm lại.
4. Quản lý thời hạn tùy thời điểm - 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.
5. 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ỉ khả thi với phần mềm chuyên dụng hoặc chuẩn bị thủ công.
6. 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 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 phát sinh chi phí một cách vô ích khi lý do không còn nữa (nhân viên đã rời đi, không còn cần tính lương)? Nhưng việc gom bộ tài liệu cho cuộc kiểm tra sau đó lại phát sinh chi phí bổ sung 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.
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ũ - để làm cho 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 yêu cầu GoBD, vì cũng phải đảm bảo 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ế là không duy trì các tài khoản đám mây không dùng đến theo cách phát sinh chi phí. Chính sự căng thẳng này là động lực cốt lõi của GitCover: Git-Bundles mang tính 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ăn cứ 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ó một căn cứ pháp lý rõ ràng - trong Bộ luật Thuế (Abgabenordnung - AO) và trong GoBD (Nguyên tắc về việc ghi sổ, lưu giữ sổ sách, ghi chép và tài liệu đúng quy định ở dạng điện tử cũng như về truy cập dữ liệu, văn bản của BMF).

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

"Khi ghi sổ và thực hiện các ghi chép cần thiết khác trên vật mang dữ liệu, đặc biệt phải đảm bảo 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ử phải đảm bảo 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ừ hạch toán, § 147 Abs. 3 AO) rằng dữ liệu luôn sẵn có và có thể đọ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 phát sinh chi phí bổ sung, 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 tại khoản 1 cũng có thể được lưu giữ dưới dạng bản tái hiện 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 ghi sổ đúng quy định và được đảm bảo 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 làm cho đọc được ngay lập tức và có thể được đánh giá bằng máy."

Lặp lại: “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ũ phải được kích hoạt lại trước 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 bày tài liệu phải lưu giữ dưới dạng bản tái hiện 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ụ tự chịu chi phí cung cấp những phương tiện hỗ trợ cần thiết để làm cho tài liệu có thể đọc được."

Điều đó có nghĩa: 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 đây 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.

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ế có thể, trong khuôn khổ một cuộc kiểm tra bên ngoài [...], yêu cầu rằng dữ liệu được cung cấp để đánh giá bằng máy theo các yêu cầu của mình."

Trong một cuộc 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à 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 quy trình (GoBD Rz. 64–91): Mỗi hệ thống ghi sổ đ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 thay đổi hệ thống, tài liệu quy trình phải được cập nhật liên tục.
• Thay đổi hệ thống/di chuyển (GoBD Rz. 146–150): Khi thay đổi hệ thống, phải đảm bảo rằng dữ liệu của hệ thống cũ vẫn tiếp tục 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 thay đổi.
• 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 như các 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 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 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 là 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:

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

Kể từ ngày 1 tháng 1 năm 2025, hóa đơn điện tử là bắt buộc đối với các giao dịch giữa các doanh nghiệp trong nước (§ 14 UStG, Wachstumschancengesetz). 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 ở 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 - kể từ năm 2025, nó là một “hóa đơn khác”.

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ữ: 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 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 nêu 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 ở 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 trực quan hóa PDF chỉ là chỉ dẫn 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, kể từ năm 2025 phần có cấu trúc (XML) là yếu tố quyết định (BMF FAQ câu hỏi 12a). Hình ảnh PDF không còn là yếu tố dẫn đầu.

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

Hóa đơn điện tử là chứng từ hạch toán theo nghĩa của § 147 Abs. 1 Nr. 4 AO và do đó phải được lưu giữ tám năm (§ 147 Abs. 3 AO). Là tài liệu điện tử, chúng phải tuân theo 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 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.
• 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 thay đổi. Git đáp ứng điều này thông qua tính không thể thay đổi sau commit (mã băm SHA-256).

Quy định toàn EU: EN 16931 và Richtlinie 2014/55/EU

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

• Richtlinie 2014/55/EU - buộc các cơ quan mua sắm 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) - việc mở rộng toàn EU theo kế hoạch đối với nghĩa vụ hóa đơn điện tử và giới thiệu một hệ thống báo cáo cho dữ liệu giao dịch. Nghĩa vụ hóa đơn điện tử của Đức chuẩn bị cho ViDA.

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

Mẹo thực tiễn: Một Git-Repo có thể lưu 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 (lược đồ XRechnung/ZUGFeRD). Như vậy, thời hạn chuyển tiếp 2025–2027 được bắc cầu mà không có điểm gãy phương tiện.

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

Lưu ý - nghĩa vụ của doanh nghiệp siêu nhỏ từ 1 nhân viên: Thường ngay cả doanh nghiệp siêu nhỏ cũng đã phải tuân theo các nghĩa vụ như vậy từ 1 nhân viên - ghi nhận thời gian 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ý an sinh xã hội (SGB IV). Vì vậy, các nghĩa vụ từ 1 nhân viên được đề cập trong Phần IV không phải là chủ đề đặc biệt của doanh nghiệp lớn, mà đặc biệt áp dụng cho các doanh nghiệp siêu nhỏ và nhỏ lần đầu tuyển dụng nhân sự. GitCover hướng đến ngưỡng này một cách có chủ ý - bước chuyển từ doanh nhân đơn lẻ sang người sử dụng lao động là thời điểm quan trọng khi các nghĩa vụ tuân thủ tăng vọt. Các nghĩa vụ từ khi đăng ký kinh doanh (phân loại lĩnh vực, miễn trừ VBG, các khoản trọn gói) đã được đề cập trong Phần II - chúng phát sinh không cần 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 thuộc tính khiến nó by Design phù hợp cho tuân thủ:

1. Tính không thể 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 về sau (GoBD Rz. 146). Các chỉnh sửa được thực hiện như các commit mới với đánh dấu lỗi thời.
2. 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.
3. 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 ngoài site) 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 “bức tranh không rõ ràng” về các rủi ro trong tương lai ngay từ đầu như thế nào:

• OSCAL - các tuyên bố tuân thủ 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 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 phân tách theo chức năng/nội dung) - Pre-Commit kiểm tra việc tách lĩnh vực, tính tuân thủ lược đồ, 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 tạo tác mã và mục nhập - 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 tắc cốt lõi của khả năng truy vết thời gian: Thời gian ghi nhận không phải là một trường riêng biệt, mà được neo ngay trong uuidV7, như dấu thời gian 48 bit theo RFC 9562 §5.7. uuidV7 được tạo từ một dấu thời gian được chỉ định trước (không phải now()) thông qua GitCover Helper (gc-v7guid), phần còn lại được điền bằng ngẫu nhiên. Nhờ đó, thời gian ghi nhận được liên kết mật mã với danh tính của tạo tác 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 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 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/gc-v7guid 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 dấu thời gian được chỉ đị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 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 ghi nhận 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 suy ra TenantId và có thể là một thời điểm được chỉ định rõ ràng thay vì thời gian hệ thống (ví dụ: từ dấu thời gian của chứng chỉ ELSTER, ngày của biên lai có TSE, v.v.) - cách diễn giải tuân theo tài liệu quy trình.

Nguyên tắc sidecar (.gc.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 dấu thời gian được chỉ định trước/dấu thời gian 48 bit được neo trong GUID
• v7g_taxonomy[].v7guid - Object ID của tài liệu được phân loại
• sha256 - 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ả hành vi phân loại - 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 - điều gì hôm nay rẻ (cheap) và ngày mai trở nên có độ tin cậy 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 ‘agent’ chỉ trong khoảnh khắc) trở thành bằng chứng có độ tin cậy 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.

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

Loạt bài theo chân một doanh nhân hư cấu (E1), người điều hành một tổ chức KMU (ký hiệu thay thế, không ràng buộc loại hình 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 về người, công ty, HRB, IBAN, mã số thuế đều được thay bằng ký hiệu thay thế.

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

Xem trước loạt bài

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

Có thể suy ra từ ED01:

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

Nguồn

• Chứng từ nguồn gốc kiểm tra SV (ẩn danh): E1/FY2025/BSFZ/Nachweise/00_BELEG_INVENTAR.md mục J
• GoBD (văn bản BMF ngày 28.11.2019, BStBl I S. 1269, sửa đổi lần cuối ngày 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ữ)
• FAQ của BMF về hóa đơn điện tử (tính đến tháng 3 năm 2026, bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html)
• EN 16931 (bộ tiêu chuẩn châu Âu, CEN/TC 434)
• Richtlinie 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)
• GitCover OSS Tool gc-v7guid - work/OSS/gc-v7guid (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

Lưu ý: Việc phân loại 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ương ứng tại git.gitcover.org/GCC để biết trạng thái hiện tại. nguồn chuẩn trên gitcover.org cho trạng thái hiện tại.