Mô hình dữ liệu hóa đơn GST: các trường tối thiểu cho HSN và đơn hàng

Những gì thường sai với hóa đơn GST

Hầu hết vấn đề với hóa đơn GST không phải là “thuế phức tạp”. Đó là vấn đề dữ liệu bị thiếu hoặc không nhất quán. Một cuộc kiểm toán thất bại khi hóa đơn không thể liên kết rõ ràng với thứ đã bán, bán cho ai, giao ở đâu và cách thuế được tính.

Một kích hoạt thường gặp là HSN bị thiếu, lỗi thời hoặc áp dụng sai cấp. Nhóm có thể lưu HSN trên sản phẩm, nhưng dòng hóa đơn được tạo từ tên SKU hoặc biến thể khác, nên HSN không bao giờ xuất hiện trên tài liệu cuối cùng. Vấn đề thường gặp khác là tách thuế sai: tính IGST khi đáng lẽ phải là CGST và SGST (hoặc ngược lại) vì “nơi cung cấp” được ước đoán từ địa chỉ giao hàng mà không lưu mã bang dùng để quyết định.

Nhóm tài chính cảm nhận điều này ngay lập tức. Việc đối soát trở thành công việc dọn dẹp hàng ngày: tổng hóa đơn không khớp với đơn hàng, đơn hàng không khớp với đối soát cổng thanh toán, và hoàn tiền trở thành chuỗi ghi chú thủ công. Ngay cả những sai khác do làm tròn nhỏ ở các dòng cũng có thể tạo ra không khớp giữa PDF hóa đơn, báo cáo GST và sổ sách.

Dưới đây là các mẫu gây ra hầu hết đau đầu không khớp:

• Sản phẩm và các dòng hóa đơn không chia sẻ cùng HSN, tỷ lệ GST và các trường giá trị chịu thuế.
• Thuế được tính ở nhiều nơi (giỏ hàng so với hóa đơn) và kết quả khác nhau.
• Tổng được lưu chỉ dưới dạng “tổng chung” mà không có phân tích cho giá trị chịu thuế và từng thành phần thuế.
• Số hóa đơn có thể chỉnh sửa hoặc bị trùng giữa các chuỗi.
• Hoàn tiền được ghi nhận như các đơn hàng âm thay vì các phiếu ghi có (credit note) đúng cách.

Mục tiêu của mô hình dữ liệu hóa đơn GST rất đơn giản: lưu một tập trường tối thiểu cho đơn hàng, sản phẩm, bên tham gia, thuế, hóa đơn và phiếu ghi có để mọi con số có thể tái tạo và giải thích sau này. Giữ cho nhỏ, nhưng đừng bỏ các trường pháp lý quan trọng quyết định loại thuế, tỷ lệ và báo cáo.

Tập bản ghi nhỏ nhất bạn cần

Nếu bạn muốn hóa đơn GST dễ tạo và dễ đối soát sau này, hãy bắt đầu với một tập đối tượng nhỏ và làm cho mỗi đối tượng chỉ làm một việc. Một mô hình dữ liệu hóa đơn GST gọn là ít về số bảng mà hơn ở việc giữ các sự thật ổn định theo thời gian.

Dưới đây là các bản ghi cốt lõi hầu hết nhóm cần ngay ngày đầu:

• Customer: người mua (tên, điện thoại/email, GSTIN nếu B2B)
• Address: giao hàng và thanh toán, cộng thêm bang và tín hiệu nơi cung cấp
• Product (or Service): thứ đã bán, với đơn vị, giá cơ sở và HSN/SAC mặc định
• Order: sự kiện thương mại (giỏ hàng, giảm giá, phí vận chuyển, trạng thái)
• Payment: cách tiền di chuyển (tham chiếu cổng, phương thức, số tiền đã thu, ngày)

Một Invoice nên tách riêng khỏi Order. Đơn hàng có thể thay đổi (địa chỉ chỉnh sửa, hàng bị huỷ, thực hiện một phần). Hóa đơn thì không nên. Hóa đơn cần số hóa đơn, ngày và tổng cố định, không bị “trôi” vì ai đó cập nhật đơn hàng sau đó.

Mấu chốt cho độ chính xác thuế là Line Items. Mỗi dòng đơn hàng (và sau này mỗi dòng hóa đơn) nên giữ chính xác số lượng, giá đơn vị, giảm giá và phân tách thuế cho từng mục cụ thể. Chính tại đó HSN/SAC và tỷ lệ GST thực sự được áp dụng.

Một chi tiết cứu nhóm tài chính: lưu ảnh chụp (snapshots). Khi bạn tạo hóa đơn, sao chép mô tả sản phẩm, HSN/SAC, tỷ lệ thuế và giá vào các dòng hóa đơn. Đừng tin vào master sản phẩm hiện tại, vì tỷ lệ và tên có thể thay đổi.

Tùy chọn nhưng thường nên thêm sớm là Returns, Refunds, và Credit Notes dưới dạng các bản ghi riêng. Ví dụ: nếu khách trả lại một món trong đơn hai món, bạn muốn một credit note tham chiếu dòng hóa đơn gốc, trong khi bản ghi hoàn tiền tham chiếu giao dịch cổng. Giữ những thứ này như đối tượng tách rời ngăn các sửa thủ công cuối tháng trong sổ GST.

Nếu bạn xây trong Koder.ai, hãy coi mỗi đối tượng như một màn hình đơn giản trước (tạo, xem, sửa), rồi thêm tạo hóa đơn chỉ sau khi snapshot và trường cấp dòng đã sẵn sàng.

HSN và SAC: vị trí trong mô hình

HSN (cho hàng hóa) và SAC (cho dịch vụ) không phải là chi tiết “chỉ trên hóa đơn”. Chúng bắt đầu ở định nghĩa sản phẩm/dịch vụ, rồi được sao chép lên từng dòng hóa đơn tại thời điểm lập hóa đơn. Điều này giữ cho giỏ hàng hỗn hợp đúng và làm cho kiểm toán dễ hơn vì mỗi dòng tự đứng vững.

Mô hình dữ liệu tối thiểu thực tế là:

• Product: id, tên, SKU, đơn vị (UOM), base_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code
• InvoiceLine: id, invoice_id, product_id (tuỳ chọn cho dòng nhập tay), mô tả, đơn vị, qty, unit_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code

Đặt HSN/SAC trên Product giúp đội admin duy trì ở một chỗ. Sao chép nó vào InvoiceLine là thứ khiến các hóa đơn cũ ổn định. Ngay cả khi sản phẩm sau đổi, hóa đơn vẫn hiển thị đúng lúc bán. Đây là cốt lõi của mô hình dữ liệu hóa đơn GST mà không vỡ khi đối soát.

Với việc lưu HSN, giữ đơn giản: mã là bắt buộc, mô tả là tuỳ chọn, và effective_from date là tuỳ chọn nếu bạn muốn lịch sử thay đổi. Hầu hết đội không cần mô tả trên mọi dòng, nhưng nó hữu ích khi tài chính kiểm tra ngoại lệ.

Giỏ hỗn hợp là bình thường: một hóa đơn có thể có nhiều dòng và do đó nhiều mã HSN/SAC. Đừng ép một mã cho toàn hóa đơn. Tổng cộng được gộp ở cấp hóa đơn, trong khi phân loại giữ ở cấp dòng.

Quản lý thay đổi là nơi mọi người gặp rắc rối. Dùng bộ quy tắc nhỏ:

• Không bao giờ ghi đè HSN/SAC trên các dòng hóa đơn đã phát hành.
• Nếu HSN/SAC sản phẩm thay đổi, cập nhật Product cho các đơn hàng trong tương lai thôi.
• Nếu bạn theo dõi lịch sử, thêm bản ghi effective_from mới thay vì sửa bản ghi cũ.

Về màn hình admin, bạn chỉ cần một chỗ để sửa trường thuế Product, kèm view chỉ đọc trên dòng hóa đơn để xác nhận những gì được lưu khi tạo hóa đơn. Nếu xây nhanh các màn này, công cụ như Koder.ai có thể sinh các trang CRUD cơ bản và bảng dữ liệu từ mô hình này với ít nỗ lực.

Thông tin các bên: GSTIN, địa chỉ và nơi cung cấp

Mô hình dữ liệu hóa đơn GST thường thất bại nhất ở thông tin các bên. Nếu nhận diện người mua hoặc người bán lệch nhẹ, hóa đơn có thể hợp lệ trên giấy nhưng gây rắc rối trong khai báo và đối soát.

Bắt đầu bằng cách coi “seller”, “buyer” và “ship-to” như các bên riêng, ngay cả khi cùng một người. Điều này ngăn các giải pháp tạm thời khi khách thêm địa chỉ giao hàng khác hoặc khi bạn bán từ nhiều đăng ký GST.

Trường tối thiểu cần lưu (người mua và người bán)

Giữ các trường nhàm chán và rõ ràng. Đây là những trường thường cần trên hóa đơn và báo cáo:

• Tên pháp lý (như sẽ xuất hiện trên hóa đơn)
• Tên thương mại (tuỳ chọn nhưng hữu ích)
• GSTIN (bắt buộc với người bán; người mua có thể để trống)
• Điện thoại/email (không luôn bắt buộc nhưng hữu ích cho hỗ trợ)
• Các dòng địa chỉ, thành phố, bang, quốc gia, mã PIN/bưu chính

Lưu bang cả tên dễ đọc và mã bang, vì báo cáo và quy tắc nơi cung cấp thường dựa vào mã.

Thanh toán vs giao hàng và nơi cung cấp

Ghi cả địa chỉ thanh toán và giao hàng trên đơn, không chỉ trong hồ sơ khách hàng. Hồ sơ thay đổi; hóa đơn thì không nên.

Nơi cung cấp nên được lưu dưới dạng mã bang cụ thể trên hóa đơn (sao chép từ đơn khi lập hóa đơn). Đừng “tính lại” sau này. Nếu quy tắc của bạn là “ship-to state”, lưu kết quả đó, cùng với bang được dùng để quyết định. Điều này làm cho kiểm toán và tranh chấp dễ hơn.

B2B vs B2C: khi nào bắt buộc GSTIN

Với B2B, GSTIN của người mua thông thường là bắt buộc và nên kiểm tra độ dài, định dạng khi nhập. Với B2C, GSTIN có thể để trống, nhưng bạn vẫn cần địa chỉ đầy đủ và bang để xác định áp dụng CGST/SGST hay IGST.

Một quy tắc đơn giản hiệu quả: nếu có GSTIN người mua thì coi là B2B; nếu không thì coi là B2C. Nếu cần ngoại lệ, lưu trường customer_type rõ ràng.

Người bán đa thực thể (nhiều GSTIN)

Nếu bạn có chi nhánh hoặc đơn vị kinh doanh với đăng ký GST khác nhau, mô hình "Seller Entity" như một bản ghi riêng với GSTIN và địa chỉ riêng. Mỗi đơn nên tham chiếu chính xác một seller entity, và mỗi hóa đơn nên sao chép các chi tiết đó để hóa đơn lịch sử vẫn chính xác ngay cả khi địa chỉ người bán thay đổi sau này.

Các công cụ như Koder.ai có thể tạo các form admin cho các bản ghi này nhanh, nhưng điểm mấu chốt là cấu trúc: seller entity riêng, snapshot tại thời điểm đơn, và mã bang nơi cung cấp rõ ràng.

Các trường tính thuế bạn phải lưu

Phân chia phổ biến nhất đơn giản: nếu nơi cung cấp cùng bang với người cung cấp, thuế là CGST + SGST. Nếu khác bang, thuế là IGST. Hệ thống của bạn không nên “tính lại từ tổng” vì những khác biệt nhỏ (làm tròn, giảm giá, phí vận chuyển) chính là thứ gây ra không khớp.

Ít nhất, lưu các số thuế ở cấp dòng hóa đơn, không chỉ ở đầu hóa đơn. Bằng vậy bạn có thể giải thích từng đồng trên hóa đơn và đối chiếu nó với sản phẩm, HSN và doanh thu.

Mẫu tối thiểu thực tế cho mỗi dòng hóa đơn trong mô hình dữ liệu GST của bạn như sau:

• taxable_value (sau phân bổ giảm giá ở cấp dòng)
• gst_rate_percent
• cgst_rate_percent, sgst_rate_percent, igst_rate_percent (lưu tách đã dùng)
• cgst_amount, sgst_amount, igst_amount (lưu các khoản đã tính)
• line_total (taxable_value + các khoản thuế)

Giảm giá là nơi hệ thống dễ bẩn. Chọn một quy tắc và lưu rõ. Nếu giảm giá giảm giá trước thuế (điển hình cho giảm giá dòng và coupon), lưu số tiền gộp ban đầu, số tiền giảm, và taxable_value kết quả. Nếu có coupon ở cấp đơn, phân bổ nó theo tỷ lệ sang các dòng (thường theo taxable value trước giảm giá) và lưu phần giảm đã phân bổ cho từng dòng để phép toán thuế dễ giải thích.

Làm tròn phải nhất quán và được ghi nhận. Chọn làm tròn ở cấp dòng hay chỉ ở cấp hóa đơn, rồi lưu kết quả đã làm tròn bạn in ra. Nhiều đội tính thuế theo dòng, làm tròn 2 chữ số thập phân, cộng lại, rồi áp một trường invoice_rounding_adjustment để đạt số phải trả chính xác.

Phí vận chuyển và xử lý không nên là phụ phí ẩn. Xử lý chúng như một dòng hóa đơn riêng với mã HSN/dịch vụ và luật thuế riêng. Ví dụ, đơn có hai sản phẩm và phí vận chuyển sẽ thành ba dòng, mỗi dòng lưu taxable value và khoản thuế, giúp đối soát tài chính dễ hơn.

Dữ liệu tài liệu hóa đơn: đánh số, ngày, tổng, trạng thái

Khi thuế đã tính xong, hóa đơn vẫn cần các trường “tài liệu” để hợp lệ, có thể kiểm toán và dễ đối soát sau này. Trong mô hình dữ liệu hóa đơn GST, coi header hóa đơn như bản ghi pháp lý: nó phải ổn định ngay cả khi dữ liệu sản phẩm hoặc khách hàng thay đổi trong tương lai.

Bắt đầu với các trường header cơ bản: số hóa đơn, ngày phát hành (ngày trên hóa đơn), loại hóa đơn (tax invoice, export, B2B, B2C, v.v.) và tiền tệ. Dù bạn chủ yếu lập bằng INR, lưu tiền tệ tránh các trường hợp phức tạp cho xuất khẩu hoặc marketplace đa tiền tệ.

Đánh số là nơi các nhóm dễ bị cháy. Giữ chuỗi hoặc tiền tố (ví dụ “FY25-INV-”), lưu năm tài chính, và bắt tính duy nhất ở mức cơ sở dữ liệu. Cũng lưu điều khiển “số tiếp theo” theo chuỗi trong admin để hai admin không thể phát hành cùng số cùng lúc.

Tổng nên được lưu rõ ràng, không chỉ suy ra. Lưu subtotal (giá trị chịu thuế), tổng thuế, grand total, và một khoản làm tròn riêng. Nếu bạn tính lại từ các dòng sau này, một thay đổi nhỏ trong quy tắc có thể khiến các hóa đơn cũ không khớp với tờ khai đã nộp.

Trạng thái nên phản ánh vòng đời thực và khoá bản ghi khi cần:

• Draft (có thể chỉnh sửa)
• Issued (đã cấp số, PDF sinh ra)
• Cancelled (giữ để kiểm toán, không xóa)
• Refunded (tiền đã hoàn, có thể cần credit note)
• Credit noted (đã phát hành credit note tham chiếu)

Cuối cùng, lưu metadata của artifacts sinh ra: phiên bản mẫu PDF, timestamp sinh, và định danh file. Băm là tuỳ chọn nhưng hữu ích nếu bạn cần chứng minh PDF không bị sửa đổi.

Ví dụ: nếu nhân viên hỗ trợ sinh lại PDF sau cập nhật mẫu, tổng và số hóa đơn phải giữ y nguyên, nhưng phiên bản mẫu lưu giải thích tại sao giao diện PDF khác.

Màn hình admin cho sản phẩm, thuế và thông tin khách hàng

Nếu bạn muốn hóa đơn GST sạch, đừng bắt đầu ở màn hình hóa đơn. Bắt đầu với các trang admin nuôi dưỡng nó. Một mô hình dữ liệu hóa đơn GST tốt giữ nhỏ khi những đầu vào này được kiểm soát và nhất quán.

Product master (SKU tới HSN/SAC)

Product master là nơi hầu hết sai khớp bắt đầu, nên giữ chặt. Mỗi SKU nên có đúng một HSN mặc định (hoặc SAC cho dịch vụ), cộng với tỷ lệ GST mặc định và mọi ngoại lệ chỉ áp dụng cho ngày nhất định.

Màn hình product thực dụng thường cần:

• SKU và tên sản phẩm (như bạn muốn in)
• Mã HSN/SAC, tỷ lệ GST, và nhóm thuế (nếu dùng)
• Ngày active from/to (để thay đổi không ghi đè hóa đơn cũ)
• Ghi đè giá (cho MRP đặc biệt hoặc giá theo kênh)
• Trạng thái (active/inactive) với lý do vô hiệu rõ ràng

Thiết lập thuế (tỷ lệ và cách phân intra vs inter-state)

Tránh UI dạng “máy tính”. Thay vào đó, lưu các đầu vào hệ thống có thể áp dụng nhất quán: bảng tỷ lệ, quy tắc nơi cung cấp bạn theo, và cách bạn quyết định intra-state so với inter-state (thường bằng cách so sánh bang người cung cấp và ship-to).

Giữ màn hình thuế tập trung vào: tỷ lệ theo nhóm/HSN, ngày hiệu lực, và điều gì xảy ra khi người mua cung cấp GSTIN hợp lệ so với không có.

Hồ sơ khách hàng và công ty (ai lên hóa đơn)

Màn hình khách hàng nên lưu GSTIN và trạng thái xác thực của nó, cùng địa chỉ thanh toán và giao hàng mặc định. Đừng để người dùng gõ bang tự do; dùng danh sách kiểm soát để “KA” và “Karnataka” không thành hai giá trị khác nhau.

Màn hình hồ sơ công ty cũng quan trọng: tên pháp lý, GSTIN, địa chỉ đăng ký và cài đặt chuỗi đánh số hóa đơn (tiền tố, số tiếp theo, ranh giới năm tài chính). Khóa phần này bằng quyền vì thay đổi ảnh hưởng mọi tài liệu tương lai.

Những cơ bản của nhật ký kiểm toán (trust và traceability)

Bạn không cần hệ thống phức tạp, nhưng cần có dấu vết. Ghi ai đã thay HSN/SAC, tỷ lệ GST, cài đặt chuỗi hóa đơn, cùng giá trị cũ, giá trị mới, timestamp và lý do.

Nếu bạn xây màn hình này trong công cụ như Koder.ai, coi nhật ký kiểm toán và ngày hiệu lực là trường quan trọng từ ngày đầu. Chúng tốn ít để thêm sớm và cứu hàng giờ khi tài chính rà soát sau này.

Từng bước: từ đơn hàng tới hóa đơn hợp quy

Hóa đơn hợp quy ít về định dạng đẹp mà hơn về đóng băng các sự thật đúng lúc. Nếu bạn thiết kế mô hình dữ liệu hóa đơn GST quanh luồng này, công việc tài chính sẽ là so khớp đơn giản, không phải điều tra hàng tuần.

1) Khóa những gì khách thực sự mua

Trước khi tính thuế, khoá snapshot đơn: mục, số lượng, đơn giá, giảm giá, phí vận chuyển/xử lý, GSTIN khách (nếu có), địa chỉ thanh toán và giao hàng, và tín hiệu nơi cung cấp. Snapshot không nên thay đổi ngay cả khi giá sản phẩm hay ánh xạ HSN sau đó thay đổi.

2) Biến snapshot thành các dòng hóa đơn (với thuộc tính thuế đã sao chép)

Tính thuế và tạo dòng hóa đơn từ snapshot. Mỗi dòng hóa đơn nên sao chép HSN/SAC, tỷ lệ thuế, giá trị chịu thuế và khoản thuế dùng tại thời điểm đó, thay vì tra cứu trực tiếp sau này.

3) Phát hành hóa đơn và làm cho nó bất biến

Gán số hóa đơn và ngày phát hành, rồi đánh dấu hóa đơn là đã phát hành. Từ lúc này, khoá các chỉnh sửa về giá, tỷ lệ thuế, mã HSN và địa chỉ trên bản ghi hóa đơn. Nếu cần cho phép gì, chỉ cho phép ghi chú không liên quan tài chính và thẻ nội bộ.

4) Tạo tài liệu cuối cùng và lưu tổng

Sinh PDF/view in từ hóa đơn đã phát hành, rồi lưu các tổng cuối cùng bạn sẽ báo cáo: tổng chịu thuế, tổng CGST/SGST/IGST, làm tròn và tổng phải trả. Nếu muốn an toàn hơn, lưu phiên bản tài liệu hoặc checksum để chứng minh in khớp với số lưu.

5) Xử lý thay đổi theo cách pháp lý

Sau khi phát hành, thay đổi nên theo quy tắc, không phải chỉnh sửa:

• Khách muốn sửa giá: phát hành credit note (hoặc debit note) tham chiếu hóa đơn gốc.
• Đơn bị huỷ sau phát hành: huỷ hóa đơn nếu được phép, nếu không thì phát hành credit note.
• Khách sửa địa chỉ sau phát hành: không ghi đè hóa đơn; sửa bằng tài liệu đúng và giữ nhật ký.
• Hoàn tiền một phần: credit note cho đúng dòng/khối lượng hoàn tiền.
• Gửi hàng thay thế: tạo đơn/hóa đơn mới, không sửa lặng lẽ.

Nếu bạn xây luồng này vào màn hình admin, đội bạn có thể tạo hóa đơn nhanh mà không phá vỡ việc đối soát sau này.

Làm cho việc đối soát dễ: thanh toán, hoàn tiền và sổ

Đối soát rối khi thanh toán được xem là cờ "đã trả/chưa trả" trên đơn. Giữ thanh toán và hoàn tiền như bản ghi riêng trỏ tới đơn và hóa đơn, để tài chính có thể đối soát bút toán ngân hàng mà không viết lại lịch sử.

Tách bản ghi thanh toán và hoàn tiền (đừng sửa hóa đơn)

Hóa đơn hợp quy nên bất biến sau khi phát hành. Nếu khách trả góp, hoặc bạn hoàn tiền sau, ghi chuyển động đó như mục thanh toán hoặc hoàn tiền, không chỉnh sửa tổng hóa đơn.

Các trường tối thiểu thường giúp đối soát dễ:

• Payment: payment_id, order_id, invoice_id, method, gateway_name, gateway_payment_id, amount, currency, authorized_at, captured_at, settlement_date, status
• Settlement (tuỳ chọn nhưng hữu ích): settlement_id, gateway_payout_id, settlement_date, gross_amount, fees, net_amount
• Refund: refund_id, order_id, invoice_id, payment_id, credit_note_id (nếu phát hành), gateway_refund_id, amount, reason, refunded_at, status
• Các khoá đối soát không bao giờ dùng lại: order_id, invoice_id, payment_id, refund_id, credit_note_id

Nếu khách trả lại một món, đừng “giảm hóa đơn.” Phát hành credit note và liên kết nó với hóa đơn gốc. Sổ hóa đơn giữ sạch, và hoàn tiền nối về credit note.

Góc nhìn tài chính và xuất file giúp tiết kiệm giờ

Cho tài chính một màn duy nhất trả lời: đã phát hành gì, đã thanh toán gì, còn mở gì, và đã đảo ngược gì. Bao gồm ageing (0-7, 8-30, 31-60, 60+ ngày) và drill-down tới thanh toán và hoàn tiền liên quan.

Các xuất file thường cần hàng tháng:

• Sổ hóa đơn (đã phát hành, huỷ, đã ghi có)
• Tổng hợp thuế theo tỷ lệ và HSN/SAC (hỗ trợ mô hình dữ liệu GST của bạn)
• Đối soát Thanh toán vs Hóa đơn (invoice_id, tổng thanh toán, số dư)
• Sổ hoàn tiền và credit note
• Báo cáo đối soát cổng (payout_id tới mapping invoice/payment)

Ví dụ: một đơn Rs 10,000, thanh toán Rs 6,000 hôm nay và Rs 4,000 tuần sau. Hóa đơn vẫn Rs 10,000. Góc nhìn tài chính hiện số dư Rs 4,000 cho tới khi đối soát thứ hai về, rồi đánh dấu đã thanh toán đầy đủ mà không sửa tài liệu đã phát hành.

Cạm bẫy thường gặp gây vấn đề tuân thủ và không khớp

Hầu hết vấn đề hóa đơn GST không phải là “logic thuế”. Là vấn đề ghi chép: số trên PDF không khớp với xuất báo cáo, hoặc hóa đơn không thể giải thích vài tháng sau.

Cạm bẫy đầu tiên là tính GST chỉ khi xem. Nếu bạn tính CGST/SGST/IGST mỗi lần ai đó mở hóa đơn, bạn sẽ cuối cùng có kết quả khác sau khi thay đổi tỷ lệ, quy tắc làm tròn, hoặc sửa lỗi. Lưu phân tách thuế đã tính tại thời điểm phát hành, ngay cả khi bạn cũng lưu các đầu vào.

Cạm bẫy thứ hai là cho phép chỉnh sửa hóa đơn đã phát hành. Một khi hóa đơn cuối cùng, thay đổi nên qua credit note hoặc luồng thay thế với nhật ký. Nếu không, bạn sẽ thấy tranh luận “tại sao PDF khách khác với sổ sách?”.

Dưới đây là các mẫu không khớp xuất hiện thường xuyên trong mô hình dữ liệu hóa đơn GST:

• Nơi cung cấp bị thiếu hoặc mã bang sai, nên áp IGST khi lẽ ra CGST+SGST (hoặc ngược lại).
• HSN/SAC sản phẩm hoặc tỷ lệ thuế được cập nhật, và đơn cũ bị tính lại bằng giá trị mới.
• Thuế được lưu, nhưng quy tắc làm tròn khác nhau giữa UI, sinh PDF và xuất CSV.
• Giảm giá áp sau thuế ở chỗ này và trước thuế ở chỗ khác.
• Hoàn tiền được ghi như dòng âm mà không liên kết rõ với hóa đơn gốc.

Một ví dụ nhanh: bạn bán cho khách ở Karnataka, nhưng địa chỉ giao hàng ở Maharashtra. Nếu hệ thống lấy bang thanh toán làm nơi cung cấp nhầm, bạn có thể thu CGST+SGST thay vì IGST. Nếu bạn cũng tính lại thuế mỗi lần xem, lỗi đó có thể “tự sửa” sau này, để lại tài chính với các con số không khớp hóa đơn đã phát hành.

Khi bạn xây màn admin (dù tùy chỉnh hay qua nền tảng như Koder.ai), thêm các rào bảo nhỏ: khoá hóa đơn đã phát hành, hiển thị inputs nơi cung cấp cạnh kiểu thuế tính được, và giữ snapshot bất biến của HSN, tỷ lệ và làm tròn dùng tại thời điểm phát hành.

Danh sách kiểm tra nhanh và bước tiếp theo

Trước khi gửi hóa đơn cho khách hoặc đánh dấu là “đã phát hành”, chạy một tập kiểm tra nhanh. Đây là nơi hầu hết sai nhỏ thành rắc rối lớn khi đối soát sau này. Nếu bạn xây mô hình dữ liệu hóa đơn GST, đáng để tích các kiểm tra này vào cả quy tắc xác thực và UI admin.

Kiểm tra trên mỗi hóa đơn (trước khi phát hành)

• HSN/SAC có trên mọi dòng và khớp với sản phẩm/dịch vụ thực tế bán.
• Quy tắc GSTIN được áp đúng (B2B vs B2C), và thông tin thanh toán/giao hàng không mâu thuẫn.
• Nơi cung cấp được lưu và phân chia thuế hợp lý (CGST/SGST vs IGST).
• Tổng cộng chính xác: giá trị chịu thuế, từng thành phần thuế, làm tròn và tổng chung.
• Sau khi phát hành, hóa đơn bị khoá (không chỉnh sửa lặng lẽ). Sửa chữa qua credit note hoặc hủy, không ghi đè lịch sử.

Ví dụ đơn giản: khách cập nhật địa chỉ giao hàng sau thanh toán, thay đổi bang. Nếu bạn phát hành lại cùng số hóa đơn với thuế mới, sổ và bản ghi thanh toán sẽ mất khớp. Cách an toàn hơn là giữ hóa đơn gốc bất biến và tạo tài liệu điều chỉnh.

Kiểm tra dữ liệu + quy trình (giữ tài chính sạch)

• Đánh số hóa đơn duy nhất, tuần tự theo chính sách, và chỉ sinh khi "issue".
• Lưu các khoản thuế đã tính, không chỉ tỷ lệ, để báo cáo ổn định ngay cả khi tỷ lệ thay đổi sau.
• Bước trạng thái rõ ràng tồn tại: draft -> issued -> cancelled (và credit note riêng).
• Báo cáo đối soát theo kỳ: tổng sổ hóa đơn phải liên kết với thanh toán đã thu, hoàn tiền đã xử lý và công nợ còn lại.
• Trường audit luôn có: created_by, issued_at, và lý do cho huỷ hoặc credit note.

Bước tiếp theo: thực hiện các màn hình và xác thực trước, rồi lặp. Trong Koder.ai, bắt đầu với Chế độ Lập kế hoạch để phác thảo bản ghi và màn admin (sản phẩm với ánh xạ HSN/SAC, chi tiết khách/GSTIN, quy tắc thuế và hóa đơn). Sinh ứng dụng, thử vài đơn thực tế end-to-end, rồi dùng snapshot và rollback để tinh chỉnh an toàn quy trình. Khi cần tuỳ chỉnh sâu hơn hoặc rà soát, xuất mã nguồn và tiếp tục phát triển theo quy trình bình thường của bạn.