Hóa đơn điện tử khi bán hàng trên website cần được quản lý từ chính dữ liệu đơn hàng thay vì tách riêng khỏi hệ thống bán hàng. Nếu website ghi nhận một mức doanh thu nhưng hóa đơn và thanh toán lại theo số liệu khác, việc đối chiếu cuối kỳ sẽ rất khó khăn.
Một đơn hàng trên website tại Bắc Ninh thực sự bắt đầu nghĩa vụ hóa đơn từ đâu?
Với hoạt động bán hàng qua website, việc phát sinh một đơn hàng và việc phát sinh thời điểm phải lập hóa đơn là hai mốc cần được tách riêng. Theo quy định hiện hành từ ngày 01/7/2026, khi bán hàng hóa, người bán phải lập hóa đơn điện tử; thời điểm lập hóa đơn đối với bán hàng hóa về nguyên tắc là thời điểm chuyển giao quyền sở hữu hoặc quyền sử dụng hàng hóa cho người mua, không phụ thuộc việc đã thu tiền hay chưa. Vì vậy, doanh nghiệp tại Bắc Ninh cần thiết kế quy trình website dựa trên diễn biến thực tế của giao dịch, thay vì cứ có Order ID là tự động xem đó là doanh thu hoàn tất.
Khách thêm sản phẩm vào giỏ hàng có được xem là phát sinh doanh thu?
Việc khách đưa sản phẩm vào giỏ hàng về bản chất mới thể hiện ý định mua. Khách vẫn có thể thay đổi số lượng, xóa sản phẩm, đóng trình duyệt hoặc không thực hiện bước đặt hàng cuối cùng. Vì vậy, dữ liệu giỏ hàng nên được website quản lý như dữ liệu hành vi mua sắm, không nên tự động chuyển thành doanh thu hoặc dữ liệu yêu cầu lập hóa đơn.
Nếu phần mềm kế toán lấy cả giỏ hàng chưa hoàn tất để cộng vào doanh số, số liệu trên website sẽ bị phình lên so với lượng hàng thực tế đã bán. Cách an toàn là thiết lập các trạng thái riêng cho giỏ hàng, đơn mới, đơn xác nhận, đơn đang giao, giao thành công, hủy và hoàn để kế toán chỉ tiếp nhận những giao dịch đạt điều kiện xử lý tiếp theo.
Đặt hàng thành công khác gì với giao dịch bán hàng hoàn tất?
“Đặt hàng thành công” thường chỉ có nghĩa hệ thống đã ghi nhận yêu cầu mua của khách và tạo một mã đơn hàng. Sau bước này, cửa hàng vẫn có thể phải kiểm tra tồn kho, xác nhận thông tin khách, xác minh phương thức thanh toán hoặc liên hệ lại trước khi giao. Do đó, trạng thái đặt hàng thành công không nên mặc định đồng nghĩa với việc giao dịch đã hoàn tất.
Một giao dịch bán hàng hoàn tất cần được nhìn trong toàn bộ chuỗi dữ liệu gồm hàng hóa, trạng thái giao nhận, thông tin thanh toán và nghĩa vụ hóa đơn. Website càng phân biệt rõ các giai đoạn này thì việc đồng bộ sang phần mềm kế toán càng chính xác, đồng thời giảm tình trạng đơn mới tạo đã bị tính doanh thu nhưng sau đó lại hủy.
Website xác nhận đơn nhưng chưa giao hàng cần xử lý thế nào?
Khi website đã xác nhận đơn nhưng hàng vẫn nằm trong kho, doanh nghiệp nên duy trì đơn ở trạng thái chờ xử lý hoặc chờ giao, đồng thời giữ đầy đủ thông tin sản phẩm, số lượng, đơn giá, mã giảm giá và thông tin khách. Việc xác nhận đơn giúp doanh nghiệp chuẩn bị hàng nhưng không nên tự động biến trạng thái này thành “đã hoàn thành” chỉ vì hệ thống đã gửi email hoặc tin nhắn xác nhận cho khách.
Đối với bán hàng hóa, mốc quan trọng về hóa đơn gắn với việc chuyển giao quyền sở hữu hoặc quyền sử dụng hàng hóa, không đơn thuần là lúc website xác nhận đơn. Vì thế, nếu doanh nghiệp muốn tự động hóa hóa đơn, điều kiện kích hoạt cần được gắn với trạng thái nghiệp vụ phù hợp thay vì chỉ dựa vào nút “Xác nhận đơn”.
Vì sao trạng thái đơn hàng quyết định chất lượng dữ liệu hóa đơn?
Trạng thái đơn hàng là cầu nối để hệ thống hiểu một giao dịch đang ở giai đoạn nào. Nếu website chỉ có hai trạng thái “mới” và “hoàn thành”, kế toán rất khó phân biệt đơn đang đóng gói, đang vận chuyển, đã giao, giao thất bại, đang chờ hoàn tiền hay đã trả lại hàng. Mỗi trường hợp lại tạo ra cách xử lý kế toán và hóa đơn khác nhau.
Một hệ thống tốt nên giữ lịch sử chuyển trạng thái theo thời gian, người thao tác và nguyên nhân thay đổi. Khi cần kiểm tra một hóa đơn cụ thể, kế toán có thể truy ngược từ mã hóa đơn về Order ID, thời điểm giao hàng và trạng thái cuối cùng mà không phải hỏi lại bộ phận bán hàng.
Sai ngay từ bước đầu có thể khiến doanh thu và hóa đơn lệch nhau ra sao?
Sai lệch thường bắt đầu khi website ghi nhận doanh thu quá sớm hoặc quá muộn. Ví dụ, 100 đơn được đặt trong ngày nhưng chỉ 80 đơn giao thành công, nếu hệ thống đưa cả 100 đơn vào doanh thu thì kế toán sẽ phải xử lý lại 20 đơn hủy hoặc giao thất bại. Ngược lại, nếu chỉ chờ tiền về ngân hàng mới ghi nhận, doanh nghiệp có thể bỏ sót những đơn đã chuyển giao hàng nhưng khách mua theo công nợ.
Vì vậy, doanh thu, giao hàng, thanh toán và hóa đơn cần có những trường dữ liệu riêng. Kế toán không nên tìm một con số duy nhất trên website rồi coi đó là số liệu cuối cùng mà cần hiểu rõ tiêu chí hình thành của từng báo cáo.
Bản đồ dòng chảy “đơn hàng – hàng hóa – tiền – hóa đơn” của một website bán hàng
Một website bán hàng vận hành tốt không chỉ quản lý đơn mà phải kết nối bốn dòng dữ liệu: đơn hàng, hàng hóa, tiền và hóa đơn. Bốn dòng này có thể di chuyển với tốc độ khác nhau nhưng cuối cùng phải đối chiếu được với cùng một mã giao dịch. Khi doanh nghiệp tại Bắc Ninh xây dựng được cấu trúc đó từ đầu, kế toán có thể kiểm soát hàng nghìn đơn bằng ngoại lệ thay vì dò thủ công từng giao dịch.
Dòng đơn hàng đi từ website đến bộ phận xử lý
Dòng đơn hàng bắt đầu khi khách hoàn tất thao tác đặt mua và website sinh mã Order ID. Sau đó, thông tin cần được chuyển sang bộ phận bán hàng hoặc hệ thống quản lý đơn để kiểm tra tồn kho, xác nhận giá, ưu đãi, địa chỉ giao nhận và phương thức thanh toán.
Điểm quan trọng là dữ liệu ban đầu không nên bị nhập lại bằng tay. Nếu nhân viên phải đọc website rồi gõ lại sang Excel hoặc phần mềm bán hàng, nguy cơ sai số lượng, sai giá và mất mã đơn sẽ tăng mạnh. Order ID cần được giữ xuyên suốt toàn bộ quy trình.
Dòng hàng hóa đi từ kho đến khách hàng
Sau khi đơn được duyệt, kho tiếp nhận yêu cầu xuất hàng, xác nhận số lượng thực tế và tạo thông tin đóng gói. Từ đây cần phát sinh liên kết giữa Order ID, mã SKU, phiếu xuất kho và mã vận chuyển để kế toán sau này có thể chứng minh hàng của đơn nào đã thực sự rời kho.
Khi giao hàng thành công hoặc thất bại, trạng thái từ đơn vị vận chuyển cần quay trở lại hệ thống. Nếu kho ghi đã xuất nhưng website không cập nhật việc khách từ chối nhận, số liệu tồn kho và doanh thu sẽ nhanh chóng lệch nhau.
Dòng tiền đi qua ngân hàng, COD hoặc cổng thanh toán
Tiền của một đơn website có thể xuất hiện ngay khi khách chuyển khoản, vài ngày sau khi đơn COD được đối soát hoặc thậm chí nhiều tuần sau nếu khách doanh nghiệp mua công nợ. Vì vậy, ngày nhận tiền không phải lúc nào cũng trùng với ngày giao hàng hoặc thời điểm lập hóa đơn.
Hệ thống nên lưu riêng số tiền phải thu, số tiền đã thu, phương thức thanh toán, mã giao dịch ngân hàng hoặc cổng thanh toán, phí bị khấu trừ và ngày thực nhận. Có như vậy kế toán mới phân biệt được doanh thu với dòng tiền.
Dòng dữ liệu hóa đơn đi từ phần mềm bán hàng đến hệ thống hóa đơn điện tử
Khi giao dịch đạt điều kiện lập hóa đơn, phần mềm bán hàng cần chuyển những trường dữ liệu cần thiết sang hệ thống hóa đơn điện tử như Order ID, tên hàng, số lượng, đơn giá, khoản giảm giá, thuế suất, thông tin người mua và tổng tiền. Việc đồng bộ trực tiếp giúp giảm thao tác nhập lại và hạn chế sai lệch giữa đơn hàng với hóa đơn.
Sau khi hóa đơn được lập, hệ thống cũng cần trả ngược số hóa đơn, ký hiệu, thời điểm lập và trạng thái xử lý về đơn hàng. Nhờ đó, nhân viên chỉ cần mở một Order ID là có thể biết hóa đơn tương ứng đã được phát hành hay chưa.
Bốn dòng dữ liệu cần gặp nhau ở đâu để kế toán không phải xử lý thủ công?
Điểm gặp tốt nhất là một mã giao dịch trung tâm, thường có thể sử dụng Order ID hoặc mã bán hàng nội bộ. Mã này phải xuất hiện trong dữ liệu website, kho, vận chuyển, thanh toán, phần mềm kế toán và thông tin liên kết với hóa đơn.
Khi tất cả hệ thống cùng nhận diện một giao dịch bằng một khóa chung, kế toán có thể thiết lập đối soát tự động. Chỉ những đơn có chênh lệch như đã giao nhưng chưa có hóa đơn, đã hoàn tiền nhưng chưa điều chỉnh hoặc tiền COD thiếu mới được đưa vào danh sách ngoại lệ cần kiểm tra.
Thời điểm lập hóa đơn – “nút thắt” lớn nhất khi bán hàng qua website
Thời điểm lập hóa đơn là nội dung dễ bị nhầm khi doanh nghiệp đồng nhất ngày đặt hàng, ngày thanh toán và ngày giao hàng. Theo Nghị định 254/2026/NĐ-CP đang áp dụng từ ngày 01/7/2026, đối với bán hàng hóa, thời điểm lập hóa đơn là thời điểm chuyển giao quyền sở hữu hoặc quyền sử dụng hàng hóa cho người mua, không phân biệt đã thu được tiền hay chưa. Đây nên là nguyên tắc trung tâm khi xây luồng xử lý hóa đơn cho website bán hàng.
Không nên mặc định thời điểm khách đặt hàng là thời điểm xuất hóa đơn
Một đơn hàng được tạo lúc 8 giờ sáng có thể đến 16 giờ mới được đóng gói và hôm sau mới giao cho khách. Nếu website lập hóa đơn ngay khi khách nhấn “Đặt hàng”, doanh nghiệp có thể phải xử lý thêm rất nhiều trường hợp khách đổi ý, hết hàng hoặc giao thất bại.
Do đó, doanh nghiệp nên xác định trạng thái nghiệp vụ nào thực sự thể hiện việc chuyển giao hàng hóa theo mô hình bán hàng của mình. Đây mới là cơ sở để cấu hình hệ thống, thay vì dùng thời điểm tạo đơn như một mốc chung cho tất cả giao dịch.
Hàng đã giao nhưng khách chưa thanh toán thì xử lý ra sao?
Việc khách chưa thanh toán không đồng nghĩa doanh nghiệp được chờ đến ngày thu tiền mới lập hóa đơn đối với hàng hóa đã chuyển giao. Quy định hiện hành xác định thời điểm lập hóa đơn bán hàng hóa không phụ thuộc việc đã thu tiền hay chưa thu tiền.
Vì vậy, những đơn mua công nợ cần được quản lý đồng thời ở hai trạng thái: giao dịch bán hàng đã phát sinh và khoản phải thu khách hàng vẫn còn. Nếu chỉ dựa vào sao kê ngân hàng, kế toán sẽ dễ bỏ sót doanh thu bán chịu.
Khách thanh toán trước nhưng hàng chưa giao có phải xuất ngay?
Đối với hoạt động bán hàng hóa thông thường, việc khách chuyển tiền trước không nên được dùng một cách máy móc làm mốc lập hóa đơn nếu quyền sở hữu hoặc quyền sử dụng hàng hóa chưa được chuyển giao. Cần xem bản chất hợp đồng, điều kiện giao nhận và thời điểm chuyển giao thực tế để xác định đúng mốc.
Website vì thế nên phân biệt rõ “đã thanh toán” với “đã hoàn thành giao dịch”. Một đơn prepaid có thể đã thu đủ tiền nhưng vẫn đang chờ xuất kho, và hai trạng thái này cần được lưu độc lập.
Đơn hàng có nhiều lần giao nên xác định thời điểm như thế nào?
Những đơn hàng lớn có thể được chia thành nhiều đợt giao do thiếu tồn kho, khách yêu cầu giao từng địa điểm hoặc có lịch nhận hàng khác nhau. Khi đó, hệ thống không nên chỉ có một trạng thái chung cho toàn bộ đơn mà cần theo dõi lượng hàng đã giao và lượng hàng còn lại.
Việc xác định hóa đơn cần bám vào từng lần chuyển giao thực tế và quy định áp dụng cho giao dịch cụ thể. Cấu trúc dữ liệu nên cho phép một Order ID liên kết với nhiều lần giao và nhiều chứng từ liên quan thay vì buộc tất cả phải xử lý trong một lần duy nhất.
Website cần lưu mốc thời gian nào để chứng minh quá trình giao dịch?
Một đơn hàng nên lưu được thời điểm tạo đơn, xác nhận, thanh toán, xuất kho, bàn giao cho đơn vị vận chuyển, giao thành công, hủy, hoàn, lập hóa đơn và hoàn tiền nếu có. Những mốc này tạo thành nhật ký giao dịch giúp doanh nghiệp giải thích được vì sao một hóa đơn được lập tại thời điểm cụ thể.
Giá trị của nhật ký càng lớn khi số lượng đơn tăng. Khi cơ quan quản lý hoặc kiểm toán nội bộ kiểm tra, doanh nghiệp có thể truy vết bằng dữ liệu hệ thống thay vì phụ thuộc vào lời giải thích của từng nhân viên.
Ma trận 5 phương thức thanh toán và cách kiểm soát hóa đơn
Không có một quy trình thanh toán duy nhất phù hợp với tất cả đơn website. Chuyển khoản trước, cổng thanh toán, COD, đặt cọc và công nợ tạo ra những dòng tiền rất khác nhau. Tuy nhiên, kế toán cần giữ một nguyên tắc thống nhất: phương thức thu tiền là dữ liệu thanh toán, còn thời điểm lập hóa đơn phải được xác định theo bản chất giao dịch và quy định hiện hành.
Thanh toán chuyển khoản trước khi giao hàng
Khi khách chuyển khoản ngay sau khi đặt hàng, website có thể cập nhật trạng thái “đã thanh toán” và cho phép kho tiếp tục xử lý. Tuy nhiên, trạng thái này không nên tự động được hiểu là “đã giao hàng”. Điều kiện lập hóa đơn cần được thiết kế độc lập với điều kiện xác nhận thanh toán.
Để đối soát, hệ thống nên lưu Order ID trong nội dung chuyển khoản hoặc tạo mã thanh toán riêng. Nhờ đó, kế toán có thể ghép đúng khoản tiền với đúng đơn mà không phải dò thủ công theo tên người gửi.
Thanh toán qua cổng thanh toán tích hợp trên website
Cổng thanh toán giúp website nhận được trạng thái giao dịch gần như tức thời nhưng số tiền thực nhận vào tài khoản doanh nghiệp có thể đã bị trừ phí. Vì vậy, kế toán cần phân biệt giá trị khách thanh toán, phí dịch vụ và số tiền ròng được chuyển về.
Mã giao dịch của cổng thanh toán nên được liên kết với Order ID. Nếu khách thanh toán thành công nhưng đơn bị hủy, hệ thống cũng phải chuyển sang quy trình hoàn tiền và kiểm tra tình trạng hóa đơn, tránh để giao dịch đã hủy vẫn nằm trong doanh thu hoàn tất.
Thanh toán COD khi nhận hàng
COD khiến nhiều doanh nghiệp nhầm rằng ngày đơn vị vận chuyển chuyển tiền về tài khoản mới là ngày bán hàng. Thực tế, thời điểm giao thành công và thời điểm đối tác vận chuyển thanh toán tiền thu hộ thường khác nhau.
Website cần nhận dữ liệu giao hàng thành công từ đơn vị vận chuyển, trong khi kế toán theo dõi khoản COD đang chờ đối soát như một khoản phải thu từ đối tác. Khi tiền về sau đó, nghiệp vụ chủ yếu là tất toán khoản phải thu chứ không nên tạo lại một giao dịch bán mới.
Đặt cọc trước và thanh toán phần còn lại sau
Với đơn hàng có đặt cọc, doanh nghiệp cần xác định rõ khoản tiền đó có bản chất là đặt cọc bảo đảm giao kết, thực hiện hợp đồng hay là khoản thanh toán cho hàng hóa. Không nên chỉ nhìn tên trường “deposit” trên website để quyết định cách xử lý hóa đơn.
Hệ thống nên giữ riêng số tiền đặt cọc, tổng giá trị đơn, phần còn phải thu và điều kiện chuyển cọc thành tiền thanh toán. Điều này đặc biệt cần thiết đối với sản phẩm đặt làm, hàng giá trị lớn hoặc hàng giao sau nhiều ngày.
Khách doanh nghiệp mua theo công nợ
Đơn công nợ thường được giao trước và thanh toán sau theo hạn mức đã thỏa thuận. Nếu phần mềm chỉ coi đơn “đã thanh toán” mới là doanh thu, các giao dịch B2B có thể bị bỏ sót.
Do đó, website hoặc hệ thống quản lý bán hàng cần lưu hạn thanh toán, mã khách hàng doanh nghiệp và số tiền phải thu. Hóa đơn và công nợ sau đó được liên kết với nhau nhưng vẫn là hai lớp dữ liệu khác nhau.
Đơn COD tại Bắc Ninh – vì sao không thể chỉ nhìn ngày tiền về tài khoản?
COD đặc biệt dễ tạo sai lệch vì có khoảng cách giữa thời điểm giao hàng, thời điểm shipper thu tiền và thời điểm đơn vị vận chuyển chuyển tiền cho người bán. Nếu doanh nghiệp tại Bắc Ninh chỉ dùng sao kê để xác định doanh thu, nhiều đơn đã giao thành công có thể bị ghi nhận chậm vài ngày hoặc bị gom sai kỳ. Cách kiểm soát đúng là liên kết dữ liệu giao hàng với dữ liệu đối soát COD.
Shipper thu hộ tiền nhưng ai là người có nghĩa vụ lập hóa đơn?
Trong mô hình COD thông thường, đơn vị vận chuyển chỉ thực hiện thu hộ tiền. Chủ thể bán hàng vẫn là doanh nghiệp hoặc hộ kinh doanh đứng sau website và có trách nhiệm thực hiện nghĩa vụ hóa đơn cho giao dịch bán hàng của mình, trừ trường hợp có cơ chế ủy nhiệm lập hóa đơn đáp ứng điều kiện pháp luật.
Vì vậy, không nên chờ đơn vị vận chuyển “xuất hóa đơn thay” cho giá trị hàng bán. Hóa đơn phí vận chuyển của đối tác và hóa đơn bán hàng cho khách là hai giao dịch khác nhau.
Ngày giao thành công và ngày đơn vị vận chuyển chuyển tiền khác nhau
Ví dụ khách nhận hàng ngày 20 nhưng đơn vị vận chuyển đến ngày 23 mới chuyển tiền COD. Nếu kế toán lấy ngày 23 làm ngày bán hàng chỉ vì tiền xuất hiện trên ngân hàng, dữ liệu sẽ lệch với lịch sử giao nhận.
Hệ thống cần lưu ngày giao thành công và ngày đối soát COD thành hai trường riêng. Khoảng thời gian giữa hai ngày có thể được theo dõi như khoản tiền đối tác vận chuyển đang thu hộ.
Đơn giao thất bại nhưng hệ thống đã ghi nhận doanh thu
Đây là lỗi thường xuất hiện khi doanh thu được ghi nhận ngay lúc kho bàn giao kiện hàng cho shipper. Việc hàng rời kho chưa có nghĩa khách đã nhận và giao dịch đã hoàn tất, đặc biệt với COD.
Khi đơn vị vận chuyển trả trạng thái “không giao được”, hệ thống cần đưa đơn về luồng hàng hoàn và loại khỏi nhóm giao dịch hoàn tất theo đúng nghiệp vụ. Quan trọng là không xóa lịch sử mà phải lưu đầy đủ quá trình để có thể truy vết.
Đối chiếu COD với hóa đơn như thế nào vào cuối ngày?
Cuối ngày, kế toán nên lấy danh sách đơn giao thành công làm một nguồn đối chiếu, sau đó kiểm tra tình trạng lập hóa đơn và trạng thái tiền COD. Những đơn đã giao nhưng chưa có hóa đơn hoặc có hóa đơn nhưng trạng thái giao hàng bất thường cần được đưa vào danh sách kiểm tra.
Cách làm này hiệu quả hơn việc chỉ so tổng tiền. Tổng số có thể tình cờ khớp trong khi bên trong vẫn tồn tại một đơn thừa và một đơn thiếu có giá trị bằng nhau.
Thiết lập mã đơn hàng để truy ngược từ tiền COD về hóa đơn
Order ID nên xuất hiện trong dữ liệu gửi cho đơn vị vận chuyển và trong file đối soát mà doanh nghiệp nhận lại. Khi tiền được chuyển về, mỗi khoản COD có thể truy ngược đến mã vận đơn, Order ID và cuối cùng là số hóa đơn.
Nếu không có khóa liên kết này, cuối tháng kế toán có thể phải dò hàng nghìn dòng bằng số điện thoại, tên khách hoặc số tiền, vừa tốn thời gian vừa dễ ghép nhầm.
Khách không lấy hóa đơn – website có được bỏ qua bước lập hóa đơn?
Việc khách nói “không lấy hóa đơn” không làm mất nghĩa vụ của người bán trong trường hợp pháp luật yêu cầu phải lập hóa đơn. Nguyên tắc hiện hành xác định khi bán hàng hóa, cung cấp dịch vụ, người bán phải lập hóa đơn điện tử giao cho người mua, trừ các trường hợp pháp luật quy định không phải sử dụng hóa đơn điện tử. Vì vậy, website nên được thiết kế để việc lập hóa đơn không phụ thuộc hoàn toàn vào nút “Khách có yêu cầu hóa đơn hay không”.
“Không yêu cầu hóa đơn” không đồng nghĩa “không phát sinh nghĩa vụ hóa đơn”
Khách cá nhân có thể không cần hóa đơn để hạch toán hoặc khấu trừ thuế nên thường bỏ qua phần thông tin hóa đơn. Tuy nhiên, doanh nghiệp không nên sử dụng hành vi này làm căn cứ bỏ giao dịch khỏi hệ thống hóa đơn.
Phần “yêu cầu hóa đơn” trên website nên được hiểu chủ yếu là nhu cầu cung cấp thêm thông tin người mua hoặc nhận hóa đơn qua kênh cụ thể. Nghĩa vụ của người bán cần được xử lý bằng quy trình phía sau.
Khách cá nhân không cung cấp mã số thuế xử lý thế nào?
Không phải mọi khách cá nhân đều có nhu cầu nhập mã số thuế khi mua hàng. Tùy loại hóa đơn và trường hợp áp dụng, pháp luật có quy định về nội dung thông tin người mua; riêng hóa đơn điện tử khởi tạo từ máy tính tiền có các quy định phù hợp với hoạt động bán trực tiếp cho người tiêu dùng.
Vì vậy, website không nên ép mọi khách phải có mã số thuế mới được mua hàng. Thay vào đó, cần cấu hình trường thông tin theo đúng loại hóa đơn doanh nghiệp đang sử dụng và cho phép khách cung cấp thêm dữ liệu khi cần.
Có cần bắt khách nhập đầy đủ thông tin hóa đơn khi checkout?
Nếu bắt khách nhập quá nhiều trường bắt buộc ngay tại checkout, tỷ lệ bỏ giỏ hàng có thể tăng. Với khách cá nhân, doanh nghiệp có thể thiết kế phần thông tin giao nhận tối giản và bổ sung khu vực riêng dành cho người mua cần thông tin hóa đơn chi tiết.
Đối với khách doanh nghiệp, website có thể mở thêm tên pháp lý, mã số thuế, địa chỉ và email nhận hóa đơn. Cách chia luồng này vừa giảm ma sát mua hàng vừa giúp kế toán có dữ liệu chính xác.
Cách thiết kế lựa chọn thông tin người mua mà không làm giảm tỷ lệ chốt đơn
Một cách phù hợp là cho khách chọn giữa mua cá nhân và mua cho doanh nghiệp. Khi chọn cá nhân, hệ thống hiển thị các trường cần thiết cho giao hàng; khi chọn doanh nghiệp, các trường phục vụ hóa đơn mới xuất hiện.
Dữ liệu cũng nên được lưu vào hồ sơ khách để lần mua sau không phải nhập lại. Điều này đặc biệt hữu ích với khách doanh nghiệp thường xuyên đặt hàng qua website.
Hóa đơn được gửi cho khách qua những kênh nào?
Hóa đơn điện tử có thể được cung cấp cho người mua qua phương thức điện tử phù hợp với hệ thống của doanh nghiệp, chẳng hạn email, đường dẫn tra cứu, ứng dụng khách hàng hoặc tài khoản website. Điều quan trọng là người mua có thể nhận và tra cứu được hóa đơn của mình.
Website nên lưu thông tin về việc phát hành và gửi hóa đơn, tránh tình trạng hóa đơn đã lập nhưng khách không nhận được vì sai email hoặc dữ liệu không được đồng bộ.
Website bán cho doanh nghiệp – sai một trường dữ liệu có thể phải xử lý cả hóa đơn
Bán B2B qua website đòi hỏi mức độ chính xác dữ liệu cao hơn vì người mua thường sử dụng hóa đơn cho kế toán và kê khai thuế. Chỉ một lỗi về tên pháp lý, mã số thuế hoặc thông tin giao dịch có thể khiến hai bên mất thời gian kiểm tra và xử lý hóa đơn. Vì vậy, khâu xác thực thông tin doanh nghiệp nên được thực hiện trước khi dữ liệu được chuyển sang hệ thống hóa đơn.
Kiểm tra tên pháp lý và mã số thuế của doanh nghiệp mua hàng
Website không nên cho phép khách chỉ nhập tên thương mại hoặc tên viết tắt nếu họ yêu cầu hóa đơn cho pháp nhân. Cần yêu cầu thông tin phù hợp với dữ liệu đăng ký của doanh nghiệp và kiểm tra mã số thuế trước khi phát hành hóa đơn.
Với khách mua thường xuyên, thông tin đã xác minh có thể được lưu thành hồ sơ thanh toán để giảm lỗi ở những lần mua tiếp theo.
Người đặt hàng khác người đứng tên hóa đơn xử lý thế nào?
Trong thực tế, nhân viên mua hàng có thể dùng tài khoản cá nhân để đặt đơn nhưng hóa đơn cần ghi thông tin công ty. Vì vậy, website không nên mặc định tên tài khoản đặt hàng chính là tên người mua trên hóa đơn.
Hệ thống cần tách rõ thông tin người liên hệ, người nhận hàng và thông tin chủ thể nhận hóa đơn. Ba nhóm dữ liệu có thể hoàn toàn khác nhau nhưng vẫn thuộc cùng một Order ID.
Một tài khoản website mua hàng cho nhiều doanh nghiệp
Đại lý, nhân viên mua hàng hoặc đơn vị cung ứng có thể đặt hàng cho nhiều pháp nhân khác nhau. Nếu website chỉ lưu một bộ thông tin hóa đơn cố định trong tài khoản, nguy cơ xuất nhầm cho công ty của đơn trước là rất cao.
Giải pháp là cho phép lưu nhiều hồ sơ xuất hóa đơn và yêu cầu người đặt chọn đúng hồ sơ ở mỗi giao dịch. Trước khi phát hành, hệ thống có thể hiển thị lại tên pháp lý và mã số thuế để xác nhận.
Địa chỉ giao hàng khác địa chỉ trên hóa đơn
Địa chỉ kho, công trình hoặc chi nhánh nhận hàng có thể khác địa chỉ pháp lý dùng trên hóa đơn. Đây là tình huống bình thường nhưng dễ gây lỗi nếu website chỉ có một trường “địa chỉ”.
Cần tách địa chỉ giao nhận khỏi địa chỉ phục vụ thông tin hóa đơn. Khi dữ liệu chuyển sang bên vận chuyển và phần mềm hóa đơn, mỗi hệ thống nhận đúng trường mình cần.
Cơ chế xác nhận thông tin trước khi phát hành hóa đơn
Với đơn B2B giá trị lớn, website nên có bước xác nhận cuối cùng trước khi phát hành hóa đơn, đặc biệt khi khách vừa thay đổi mã số thuế hoặc pháp nhân nhận hóa đơn. Có thể thực hiện bằng màn hình xác nhận hoặc thông báo điện tử.
Sau khi hóa đơn đã lập, việc thay đổi thông tin cần tuân thủ quy trình xử lý hóa đơn điện tử theo quy định hiện hành. Vì vậy, kiểm tra dữ liệu ngay từ đầu luôn tiết kiệm hơn sửa sai về sau.
Từ voucher đến freeship – các khoản giảm giá cần được đưa vào dữ liệu hóa đơn ra sao?
Khuyến mại, chiết khấu và hỗ trợ vận chuyển làm cho giá niêm yết trên website khác số tiền cuối cùng khách phải trả. Nghị định 254/2026/NĐ-CP quy định nội dung hóa đơn có thể thể hiện các khoản chiết khấu thương mại, khuyến mại và nội dung liên quan nếu có. Do đó, website cần truyền đầy đủ cơ chế hình thành giá cuối cùng sang hệ thống hóa đơn thay vì chỉ gửi một con số tổng.
Voucher giảm trực tiếp trên giá sản phẩm
Nếu voucher làm giảm trực tiếp giá của một sản phẩm, phần mềm cần xác định được sản phẩm nào được hưởng giảm giá và giá trị giảm tương ứng. Không nên chỉ lưu mã voucher mà không lưu tác động của voucher tới từng dòng hàng.
Khi dữ liệu chuyển sang hóa đơn, tổng giá trị hàng, khoản giảm và số tiền thanh toán phải có logic thống nhất. Điều này giúp kế toán kiểm tra lại đơn ngay cả khi chương trình khuyến mại đã kết thúc.
Mã giảm giá cho toàn bộ đơn hàng
Voucher áp dụng cho toàn đơn cần có nguyên tắc phân bổ rõ ràng nếu doanh nghiệp cần phân bổ giá trị giảm cho các mặt hàng. Điều này đặc biệt quan trọng khi đơn có sản phẩm thuộc cách tính thuế hoặc chính sách giá khác nhau.
Website nên lưu cả giá trị trước giảm, tổng giảm và giá trị sau giảm. Nếu chỉ lưu số cuối cùng, kế toán sẽ khó giải thích cách hình thành giá khi đối chiếu.
Chương trình mua 2 tặng 1
Chương trình mua 2 tặng 1 cần được cấu hình rõ sản phẩm nào là hàng bán và sản phẩm nào được khuyến mại theo chương trình. Hệ thống không nên tự ý xóa sản phẩm tặng khỏi đơn vì hàng vẫn thực tế xuất khỏi kho.
Thông tin khuyến mại cũng cần được phản ánh phù hợp trong dữ liệu hóa đơn và hồ sơ chương trình. Điều này giúp số lượng xuất kho khớp với số lượng thực tế giao cho khách.
Miễn phí hoặc hỗ trợ phí vận chuyển
Freeship có thể do người bán tự chịu, được tài trợ bởi nền tảng hoặc được trừ trực tiếp vào phí vận chuyển khách phải trả. Ba trường hợp có bản chất dữ liệu khác nhau nên website cần lưu rõ nguồn hỗ trợ.
Nếu chỉ nhìn số tiền khách chuyển, kế toán có thể nhầm phí vận chuyển với giá hàng hóa. Vì vậy, giá sản phẩm, phí vận chuyển, khoản hỗ trợ và tổng thanh toán nên được tách thành các trường riêng.
Vì sao tổng tiền khách trả phải đối chiếu được với hóa đơn?
Khách thường lấy số tiền đã thanh toán làm cơ sở phản hồi nếu phát hiện hóa đơn không khớp. Một đơn website hiển thị 1.250.000 đồng nhưng hóa đơn lại ra 1.300.000 đồng sẽ tạo ngay vấn đề chăm sóc khách hàng và kế toán.
Do đó, hệ thống phải giải thích được toàn bộ chênh lệch từ giá niêm yết đến số tiền cuối cùng thông qua giảm giá, phí vận chuyển, khuyến mại hoặc các khoản liên quan. Không nên dùng thao tác sửa tay trên hóa đơn để “làm cho khớp”.
Đơn hàng bị hủy trước khi giao – dữ liệu nào cần được “xóa dấu vết doanh thu”?
“Xóa dấu vết doanh thu” không nên hiểu là xóa lịch sử đơn hàng. Khi đơn bị hủy, hệ thống cần loại giao dịch khỏi nhóm doanh thu hoàn tất nếu chưa phát sinh nghiệp vụ bán theo điều kiện tương ứng, nhưng vẫn phải giữ nhật ký tạo đơn, lý do hủy, thanh toán và hoàn tiền. Một hệ thống có khả năng truy vết sẽ an toàn hơn nhiều so với việc nhân viên xóa đơn khỏi cơ sở dữ liệu.
Khách hủy ngay sau khi đặt hàng
Nếu khách vừa đặt rồi hủy trước khi hàng được xử lý, website chỉ cần chuyển đơn sang trạng thái hủy và ghi nhận lý do. Đơn không nên tiếp tục đi vào hàng chờ xuất kho hoặc hàng chờ lập hóa đơn.
Nếu khách đã thanh toán, hệ thống phải đồng thời tạo luồng hoàn tiền để kế toán biết đây là khoản cần trả lại chứ không phải khoản doanh thu đã hoàn tất.
Cửa hàng chủ động hủy do hết hàng
Trường hợp hết hàng cần được phản ánh về cả hệ thống bán hàng và tồn kho. Nếu website vẫn nhận đơn trong khi tồn kho bằng 0, tỷ lệ hủy sẽ tăng và kéo theo nhiều giao dịch thanh toán phải hoàn.
Khi hủy, Order ID vẫn nên được giữ nguyên để đối chiếu với giao dịch ngân hàng hoặc cổng thanh toán nếu tiền đã được thu.
Hủy sau khi đã đóng gói và giao cho đơn vị vận chuyển
Đây là trường hợp cần phân biệt “đã xuất khỏi kho” với “đã bán hoàn tất”. Hàng có thể đang trên đường nhưng khách yêu cầu hủy trước khi nhận, sau đó kiện hàng quay trở lại kho.
Website cần ghi nhận cả chiều đi và chiều hoàn để tồn kho không bị sai. Nếu hệ thống chỉ chuyển đơn thành “hủy” mà không có luồng hàng hoàn, kế toán kho sẽ khó kiểm soát.
Hủy sau khi đã phát sinh thanh toán online
Khi đã thu tiền nhưng giao dịch bị hủy trước khi hoàn tất chuyển giao, hệ thống cần liên kết đơn hủy với giao dịch hoàn tiền. Nếu đã phát sinh hóa đơn do cấu hình hoặc nghiệp vụ cụ thể, doanh nghiệp cần xử lý hóa đơn đã lập theo quy định hiện hành thay vì xóa dữ liệu.
Điều quan trọng là ba trạng thái hủy đơn, hoàn tiền và xử lý hóa đơn phải được kiểm soát đồng thời, tránh tình trạng khách đã nhận lại tiền nhưng doanh thu và hóa đơn vẫn còn nguyên.
Quy trình khóa đơn để tránh nhân viên xuất nhầm hóa đơn
Sau khi đơn chuyển sang trạng thái hủy, hệ thống nên tự động khóa nút xuất hóa đơn hoặc gửi dữ liệu hóa đơn. Nếu cần mở lại đơn, thao tác phải có quyền hạn và lưu nhật ký.
Cơ chế này đặc biệt cần khi nhiều nhân viên cùng xử lý đơn. Chỉ một người không biết đơn đã hủy cũng có thể vô tình phát hành hóa đơn nếu phần mềm không có kiểm soát trạng thái.
Hàng hoàn trả – khi dòng hóa đơn phải chạy ngược với dòng bán hàng
Đổi trả là thời điểm website, kho, tiền và hóa đơn phải cùng điều chỉnh theo một giao dịch đã hoàn tất trước đó. Theo Thông tư 91/2026/TT-BTC đang có hiệu lực từ ngày 01/7/2026, khi người mua trả lại toàn bộ hoặc một phần hàng hóa, kể cả đổi hàng làm thay đổi giá trị hàng đã mua, về nguyên tắc người bán lập hóa đơn điều chỉnh; trường hợp các bên có thỏa thuận người mua lập hóa đơn khi trả lại thì thực hiện theo cơ chế được quy định.
Khách trả lại toàn bộ đơn hàng
Khi khách trả toàn bộ đơn, hệ thống cần liên kết giao dịch hoàn với Order ID ban đầu, số hóa đơn, phiếu nhập lại kho và khoản hoàn tiền. Không nên tạo một đơn âm độc lập mà không biết nó đang điều chỉnh cho giao dịch nào.
Về hóa đơn, trường hợp trả lại hàng phải được xử lý theo quy định hiện hành về hóa đơn điều chỉnh và hồ sơ liên quan. Dữ liệu website cần cung cấp đủ căn cứ để kế toán thực hiện.
Khách chỉ trả một sản phẩm trong đơn nhiều sản phẩm
Đơn có năm sản phẩm nhưng khách trả một sản phẩm thì doanh thu và tồn kho chỉ thay đổi ở phần hàng trả lại. Vì vậy, hệ thống cần hỗ trợ hoàn theo từng dòng sản phẩm thay vì buộc hủy cả đơn.
Hóa đơn điều chỉnh cũng cần dựa trên đúng phần giá trị thay đổi. Nếu website chỉ lưu trạng thái chung “đã hoàn”, kế toán sẽ rất khó biết sản phẩm nào đã được khách giữ lại.
Khách đổi sang sản phẩm có giá cao hơn
Nếu khách trả sản phẩm cũ và nhận sản phẩm mới giá cao hơn, hệ thống phải ghi nhận phần hàng trả, hàng xuất mới và khoản tiền khách trả thêm. Chênh lệch không nên được nhập thủ công vào một ô “phụ thu” không có liên kết với sản phẩm.
Thông tư 91/2026 cũng xem trường hợp đổi hàng làm thay đổi giá trị hàng đã mua trong nhóm cần xử lý hóa đơn tương ứng với hàng trả lại. Vì vậy, dữ liệu đổi hàng phải đủ chi tiết để kế toán xác định phần điều chỉnh.
Khách đổi sang sản phẩm có giá thấp hơn
Khi sản phẩm mới rẻ hơn, ngoài hàng trả và hàng xuất mới còn phát sinh khoản tiền cần hoàn lại cho khách. Website phải liên kết khoản hoàn này với đúng đơn và đúng lý do.
Nếu kế toán chỉ nhìn sao kê, khoản chuyển tiền ra có thể bị hiểu sai thành một khoản chi phí. Order ID và hồ sơ đổi trả sẽ giúp xác định đây thực chất là điều chỉnh giao dịch bán trước đó.
Đối chiếu hóa đơn, kho và khoản hoàn tiền sau đổi trả
Sau đổi trả, ba con số cần cùng giải thích được một giao dịch: lượng hàng thực còn bán cho khách, giá trị hóa đơn sau xử lý và số tiền doanh nghiệp thực giữ lại. Nếu một trong ba không khớp, hồ sơ vẫn chưa hoàn chỉnh.
Doanh nghiệp nên sử dụng báo cáo ngoại lệ để tìm các trường hợp hàng đã nhập lại kho nhưng chưa xử lý hóa đơn hoặc đã hoàn tiền nhưng đơn chưa cập nhật trạng thái.
Một website bán hàng nhưng doanh thu xuất hiện trên nhiều “màn hình”
Doanh thu có thể xuất hiện ở dashboard website, phần mềm vận chuyển, cổng thanh toán, ngân hàng, hệ thống hóa đơn và phần mềm kế toán với các giá trị khác nhau. Không phải màn hình nào cũng sai; vấn đề là mỗi màn hình có thể dùng một tiêu chí ghi nhận khác nhau. Kế toán cần hiểu bản chất từng nguồn để xây quy tắc đối chiếu thay vì cố buộc mọi số liệu phải giống nhau tại mọi thời điểm.
Doanh thu trên trang quản trị website
Dashboard website thường tính theo đơn tạo mới, đơn hoàn thành hoặc tổng giá trị đơn tùy cấu hình. Nếu không biết định nghĩa của chỉ tiêu, người quản lý rất dễ lấy nhầm con số làm doanh thu kế toán.
Doanh nghiệp nên ghi rõ báo cáo đang lọc theo trạng thái nào và có loại đơn hủy, hoàn, giảm giá hay không. Đây là bước nhỏ nhưng giúp tránh tranh luận giữa bộ phận bán hàng và kế toán.
Doanh thu trên tài khoản ngân hàng
Tiền vào ngân hàng không đồng nghĩa hoàn toàn với doanh thu. Nó có thể gồm tiền khách trả trước, COD của đơn ngày trước, khoản khách thanh toán công nợ hoặc thậm chí khoản chuyển nhầm.
Ngược lại, đơn bán chịu đã phát sinh nhưng chưa có tiền sẽ không xuất hiện trên sao kê. Vì vậy, ngân hàng là nguồn kiểm soát dòng tiền chứ không nên là nguồn duy nhất để xác định doanh thu.
Doanh thu do đơn vị vận chuyển đối soát
Bảng đối soát vận chuyển thường phản ánh những đơn COD đã giao và số tiền đối tác sẽ trả sau khi trừ một số khoản. Con số này hữu ích nhưng có thể khác tổng giá trị hàng do phí vận chuyển, phí hoàn hoặc thời gian chốt đối soát.
Kế toán cần đối chiếu theo mã vận đơn và Order ID thay vì chỉ so tổng cuối bảng.
Doanh thu trên phần mềm hóa đơn
Phần mềm hóa đơn phản ánh giá trị các hóa đơn đã được lập, nhưng nếu hệ thống bán hàng đồng bộ chậm hoặc có hóa đơn cần điều chỉnh do trả hàng, số liệu tại một thời điểm có thể khác website.
Vì vậy, báo cáo cần phân biệt hóa đơn gốc, hóa đơn điều chỉnh và giao dịch đang chờ xử lý. Không nên cộng tất cả theo cách cơ học.
Doanh thu trên phần mềm kế toán – con số nào mới là con số cần kiểm soát?
Phần mềm kế toán là nơi tổng hợp nghiệp vụ tài chính nhưng dữ liệu đầu vào vẫn phải được đối chiếu với thực tế giao dịch. Một con số đã được hạch toán không tự động trở thành đúng nếu dữ liệu nguồn bị thiếu.
Điều kế toán cần kiểm soát là khả năng giải thích chênh lệch giữa các hệ thống. Khi mọi giao dịch đều có Order ID, việc đối chiếu sẽ chuyển từ so tổng sang kiểm tra từng ngoại lệ.
Khi website, Shopee, TikTok Shop và Facebook cùng bán một sản phẩm
Bán đa kênh giúp tăng doanh số nhưng cũng tạo nguy cơ trùng đơn, trùng doanh thu và trùng hóa đơn nếu mỗi nền tảng vận hành như một hệ thống độc lập. Doanh nghiệp cần xây một lớp quản trị trung tâm để mỗi giao dịch chỉ được ghi nhận một lần, dù đơn ban đầu xuất phát từ website, sàn thương mại điện tử hay mạng xã hội.
Vì sao bán đa kênh rất dễ xuất trùng hóa đơn?
Một đơn từ sàn có thể được đồng bộ sang phần mềm bán hàng rồi tiếp tục đẩy sang website để quản lý kho. Nếu cả sàn và hệ thống nội bộ cùng kích hoạt quy trình hóa đơn mà không nhận diện đây là cùng một giao dịch, hóa đơn có thể được lập hai lần.
Mỗi đơn cần có cả mã nguồn và mã giao dịch trung tâm. Hệ thống chỉ cho phép một trạng thái hóa đơn cuối cùng cho cùng nghiệp vụ bán hàng.
Một mã SKU nên được quản lý xuyên suốt các nền tảng
Cùng một sản phẩm nhưng website gọi “AO-001”, Shopee gọi “A001” và kho gọi “SP-25” sẽ gây khó khăn khi đối chiếu. SKU chuẩn giúp hệ thống hiểu đây là cùng một hàng hóa.
Ngoài SKU nội bộ, doanh nghiệp có thể giữ mã riêng của từng nền tảng nhưng phải có bảng ánh xạ cố định. Điều này giúp tồn kho và dữ liệu hóa đơn thống nhất.
Đơn từ sàn đổ về website có nên tạo lại hóa đơn?
Việc đơn từ sàn được đồng bộ về website nhằm mục đích quản trị không có nghĩa phải tạo một giao dịch bán mới. Website cần nhận biết nguồn đơn và tình trạng hóa đơn để không phát hành trùng.
Nguồn dữ liệu gốc của giao dịch phải được xác định ngay khi tích hợp. Mọi hệ thống phía sau chỉ kế thừa cùng Order ID hoặc mã mapping.
Xử lý đơn khách đặt online nhưng nhận hàng tại cửa hàng
Click-and-collect tạo ra giao dịch bắt đầu online nhưng hoàn tất tại điểm bán. Hệ thống cần giữ nguyên Order ID khi khách đến cửa hàng, tránh nhân viên tạo thêm một đơn POS mới khiến doanh thu bị nhân đôi.
Khi giao hàng tại quầy, trạng thái đơn online được cập nhật và dữ liệu hóa đơn đi theo cùng giao dịch đó. Nếu phát sinh thay đổi sản phẩm tại cửa hàng, hệ thống cần ghi lại phần điều chỉnh.
Xây dựng một “nguồn dữ liệu gốc” cho toàn bộ doanh thu
Nguồn dữ liệu gốc không nhất thiết phải là website. Nó có thể là ERP, phần mềm bán hàng hoặc nền tảng OMS, miễn tất cả kênh đều đẩy đơn về cùng một nơi.
Hệ thống này có nhiệm vụ loại trùng, chuẩn hóa SKU, trạng thái giao hàng, thanh toán và tình trạng hóa đơn. Khi đó kế toán chỉ cần kiểm soát một tập dữ liệu trung tâm.
Hộ kinh doanh tại Bắc Ninh bán hàng qua website cần xây quy trình hóa đơn thế nào?
Hộ kinh doanh bán online cũng cần nhìn hóa đơn như một phần của quy trình bán hàng chứ không phải công việc làm vào cuối tháng. Theo Nghị định 254/2026/NĐ-CP áp dụng từ ngày 01/7/2026, hộ kinh doanh, cá nhân kinh doanh thuộc diện quy định phải sử dụng hóa đơn điện tử phù hợp; với hộ có doanh thu năm trên 1 tỷ đồng hoặc một số trường hợp theo quy định, việc áp dụng hóa đơn điện tử có mã hoặc hóa đơn khởi tạo từ máy tính tiền cần được đặc biệt lưu ý.
Website chỉ là kênh nhận đơn hay là hệ thống bán hàng chính?
Nếu website chỉ chuyển thông tin về cửa hàng rồi mọi nghiệp vụ được xử lý trong phần mềm POS, hệ thống POS có thể là trung tâm quản trị. Ngược lại, nếu tồn kho, thanh toán và trạng thái giao hàng đều chạy trên website thì website đóng vai trò lớn hơn.
Việc xác định hệ thống chính giúp hộ kinh doanh biết dữ liệu nào là nguồn để lập hóa đơn và đối soát.
Hộ kinh doanh ít đơn có thể quản lý thủ công đến mức nào?
Với vài đơn mỗi ngày, người bán có thể kiểm tra từng giao dịch trước khi lập hóa đơn. Tuy nhiên, ngay từ giai đoạn này vẫn nên có mã đơn thống nhất và bảng theo dõi trạng thái.
Không nên chờ đến khi có hàng trăm đơn mới chuẩn hóa dữ liệu, bởi lịch sử cũ thường rất khó làm sạch khi các mã đơn và cách ghi nhận đã thay đổi nhiều lần.
Khi số lượng đơn tăng cần chuyển sang tự động hóa ở bước nào?
Bước đầu tiên nên tự động hóa là đồng bộ dữ liệu, không nhất thiết là tự động phát hành hóa đơn ngay. Website có thể tự chuyển đơn, sản phẩm, giá và thông tin khách sang phần mềm kế toán hoặc hóa đơn để giảm nhập lại.
Sau khi quy tắc ổn định, doanh nghiệp mới thiết lập điều kiện phát hành tự động và cơ chế dừng những đơn bất thường.
Hóa đơn điện tử khởi tạo từ máy tính tiền có liên quan thế nào đến mô hình bán lẻ?
Hóa đơn điện tử khởi tạo từ máy tính tiền được thiết kế phù hợp với nhiều hoạt động bán trực tiếp cho người tiêu dùng và là một trong những hình thức hóa đơn được Nghị định 254/2026 quy định. Đối tượng áp dụng cần xác định theo ngành nghề, doanh thu và hình thức hóa đơn đã đăng ký.
Đối với hộ vừa bán tại cửa hàng vừa nhận đơn website, việc lựa chọn giải pháp nên tính đến khả năng đồng bộ cả hai nguồn để tránh tồn tại hai sổ bán hàng riêng biệt.
Khi nào hộ kinh doanh nên tách riêng kế toán website và kế toán cửa hàng?
Không nhất thiết phải tách thành hai hệ thống kế toán độc lập. Điều cần tách là nguồn giao dịch để có thể biết doanh thu đến từ website hay cửa hàng, trong khi dữ liệu cuối cùng vẫn hợp nhất để quản trị.
Khi số lượng đơn lớn, việc gắn mã kênh bán giúp phân tích doanh thu, phí vận chuyển, chi phí quảng cáo và tỷ lệ hoàn mà không làm phân mảnh số liệu kế toán.
“Bộ não tự động” phía sau website – thiết kế luồng xuất hóa đơn không cần nhập lại dữ liệu
Tự động hóa tốt không phải là cứ có đơn thì lập hóa đơn ngay. Một hệ thống thông minh phải hiểu trạng thái đơn, kiểm tra dữ liệu và chỉ kích hoạt nghiệp vụ khi đủ điều kiện. Đồng thời, hệ thống phải có khả năng dừng những trường hợp bất thường để con người kiểm tra. Khi thiết kế theo nguyên tắc này, kế toán chuyển từ nhập liệu sang kiểm soát.
Order ID trở thành khóa kết nối giữa website và hóa đơn
Order ID cần được coi như “số căn cước” của giao dịch. Từ mã này có thể truy đến sản phẩm, kho, vận chuyển, thanh toán và số hóa đơn.
Nếu phần mềm hóa đơn không có trường Order ID trực tiếp, doanh nghiệp vẫn nên giữ liên kết trong hệ thống trung gian hoặc phần mềm kế toán để việc truy vết không bị mất.
Đồng bộ tên hàng, số lượng, đơn giá và thông tin người mua
Các trường dữ liệu hóa đơn không nên được nhân viên gõ lại từ màn hình website. API hoặc cơ chế tích hợp có thể chuyển trực tiếp tên hàng, số lượng, đơn giá, giảm giá và thông tin người mua.
Trước khi gửi, hệ thống nên có lớp kiểm tra dữ liệu bắt buộc và định dạng, giúp ngăn lỗi mã số thuế, số lượng âm hoặc tổng tiền không khớp.
Điều kiện nào kích hoạt việc lập hóa đơn tự động?
Điều kiện cần dựa trên nghiệp vụ thực tế, chẳng hạn trạng thái phản ánh việc chuyển giao hàng hóa theo quy trình của doanh nghiệp, đồng thời kiểm tra đơn không nằm trong trạng thái hủy hoặc hoàn bất thường.
Do quy định về thời điểm lập hóa đơn phụ thuộc bản chất giao dịch, doanh nghiệp cần cấu hình theo quy trình cụ thể thay vì sao chép máy móc điều kiện của một website khác.
Cơ chế dừng tự động khi đơn có dấu hiệu bất thường
Hệ thống nên dừng luồng nếu đơn có giá trị âm, mã số thuế không hợp lệ, giảm giá vượt giá hàng, trạng thái vận chuyển mâu thuẫn hoặc cùng Order ID đã tồn tại hóa đơn.
Những đơn này được đưa vào hàng chờ để kế toán kiểm tra. Đây là nguyên tắc “tự động hóa giao dịch bình thường, kiểm soát giao dịch ngoại lệ”.
Nhật ký hệ thống giúp truy vết sai sót khi cơ quan thuế kiểm tra
Nhật ký cần ghi ai thay đổi đơn, thay đổi lúc nào, trạng thái trước và sau, dữ liệu nào được gửi sang hệ thống hóa đơn và kết quả phản hồi. Khi xảy ra sai sót, doanh nghiệp có thể xác định nguyên nhân thay vì chỉ nhìn hóa đơn cuối cùng.
Nghị định 254/2026 cũng nhấn mạnh dữ liệu hóa đơn điện tử là cơ sở phục vụ quản lý thuế, vì vậy chất lượng và khả năng truy vết dữ liệu ngày càng quan trọng.
10 lỗi website bán hàng tại Bắc Ninh thường gặp khi triển khai hóa đơn điện tử
Sai sót hóa đơn website thường không nằm ở một thao tác duy nhất mà hình thành từ nhiều bước: ghi nhận đơn quá sớm, chờ tiền quá lâu, không đồng bộ hoàn hủy, nhập lại dữ liệu và thiếu mã liên kết. Năm nhóm vấn đề dưới đây bao quát những lỗi phổ biến có thể kéo theo nhiều sai lệch khác nhau về doanh thu, kho, thanh toán và hóa đơn.
Chờ khách yêu cầu mới xuất hóa đơn
Đây là lỗi xuất phát từ quan niệm hóa đơn chỉ phục vụ khách hàng. Trên thực tế, nghĩa vụ lập hóa đơn của người bán không phụ thuộc đơn thuần vào việc khách có nhấn nút “lấy hóa đơn” hay không.
Website nên tự xác định giao dịch thuộc diện xử lý hóa đơn, còn lựa chọn của khách chủ yếu phục vụ việc cung cấp thông tin và phương thức nhận.
Chờ tiền COD về tài khoản mới ghi nhận giao dịch
Tiền COD có thể về sau ngày khách nhận hàng. Nếu lấy ngày tiền về làm mốc cho toàn bộ nghiệp vụ, doanh thu và hóa đơn có thể bị dồn sang ngày khác.
Cần dùng dữ liệu giao hàng và quy định về thời điểm lập hóa đơn làm căn cứ, còn tiền COD được theo dõi như dòng tiền đối soát sau đó.
Gộp nhiều đơn hàng không đúng cách
Gộp đơn để giảm thao tác có thể làm mất khả năng truy vết nếu không xác định được hóa đơn đang bao gồm những Order ID nào. Khi một đơn trong nhóm bị hoàn, việc điều chỉnh trở nên phức tạp.
Nếu có quy trình xử lý tổng hợp trong trường hợp được phép, hệ thống vẫn phải giữ bảng liên kết giữa từng giao dịch gốc và dữ liệu hóa đơn.
Không cập nhật đơn hoàn và đơn hủy sang phần mềm kế toán
Website biết đơn đã hủy nhưng phần mềm kế toán vẫn giữ doanh thu cũ sẽ khiến báo cáo cuối tháng cao hơn thực tế. Tình trạng tương tự xảy ra khi kho đã nhận hàng hoàn nhưng hóa đơn chưa được xử lý.
Đơn hủy và hoàn cần được đồng bộ như một loại sự kiện bắt buộc, không phải thông tin phụ.
Website, kho, ngân hàng và hóa đơn sử dụng bốn bộ dữ liệu khác nhau
Đây là lỗi nền tảng nghiêm trọng nhất. Khi mỗi hệ thống dùng một mã hàng và một mã giao dịch riêng, kế toán phải ghép dữ liệu bằng tên khách hoặc số tiền.
Giải pháp là chuẩn hóa SKU, Order ID và nguồn đơn ngay từ đầu. Khi cấu trúc dữ liệu thống nhất, phần lớn lỗi còn lại dễ phát hiện hơn.
Case study – theo dấu một đơn hàng website tại Bắc Ninh từ 8 giờ sáng đến lúc hoàn tất
Một ví dụ thực tế giúp thấy rõ vì sao không nên dùng một mốc duy nhất cho toàn bộ giao dịch. Giả sử khách tại Bắc Ninh đặt một đơn COD lúc 8 giờ, kho xử lý lúc 9 giờ và khách nhận hàng vào 15 giờ. Trong cùng một ngày đã xuất hiện nhiều mốc khác nhau nhưng chỉ khi đặt chúng vào đúng chức năng thì kế toán mới kiểm soát được hóa đơn, hàng và tiền.
8h00 – khách đặt đơn và lựa chọn thanh toán COD
Website tạo Order ID BN250801 và ghi nhận sản phẩm, số lượng, địa chỉ, tổng tiền cùng phương thức COD. Đây là thời điểm đơn được tạo nhưng khách chưa nhận hàng và chưa trả tiền.
Hệ thống chỉ chuyển đơn sang hàng chờ xác nhận, không coi đây là khoản tiền đã thu và cũng không dùng riêng mốc này để mặc định giao dịch đã hoàn tất.
9h00 – kho xác nhận, đóng gói và tạo mã vận chuyển
Kho kiểm tra tồn, đóng hàng và kết nối Order ID với mã vận đơn. Tồn kho có thể chuyển sang trạng thái hàng đang giao để quản trị nội bộ.
Website vẫn giữ thông tin rằng giao dịch chưa có kết quả giao nhận cuối cùng, bởi khách COD có thể từ chối nhận.
15h00 – khách nhận hàng và hệ thống cập nhật trạng thái
Đơn vị vận chuyển xác nhận giao thành công và khách thanh toán cho shipper. Đây là mốc rất quan trọng vì hàng đã được chuyển giao theo thực tế giao dịch.
Dữ liệu giao thành công cần quay về hệ thống bán hàng càng sớm càng tốt để kích hoạt quy trình nghiệp vụ phù hợp, bao gồm kiểm soát hóa đơn theo quy định.
Dữ liệu đơn hàng được chuyển sang hệ thống hóa đơn
Khi điều kiện nghiệp vụ đã đáp ứng, hệ thống lấy dữ liệu từ Order ID gồm hàng hóa, số lượng, giá, giảm giá và thông tin người mua để lập hóa đơn mà không nhập lại.
Số hóa đơn sau đó được trả về hồ sơ Order ID, tạo liên kết hai chiều giữa bán hàng và hóa đơn.
Cuối ngày – kế toán kiểm tra tiền, hàng, hóa đơn và đơn hoàn
Kế toán kiểm tra các đơn giao thành công, hóa đơn đã lập và danh sách giao thất bại. Riêng COD, tiền có thể chưa về ngân hàng nên được theo dõi trong khoản chờ đối soát với đơn vị vận chuyển.
Nhờ đó, kế toán không cần đợi vài ngày đến khi COD chuyển về mới biết ngày đó đã phát sinh bao nhiêu giao dịch bán.
Checklist cuối ngày dành cho kế toán website tại Bắc Ninh
Đối soát cuối ngày không cần biến thành việc kiểm tra thủ công từng đơn nếu dữ liệu đã được chuẩn hóa. Kế toán nên tập trung vào chênh lệch giữa số đơn tạo mới, số giao thành công, số hóa đơn, số đơn hủy hoàn và tổng tiền theo từng phương thức thanh toán. Mục tiêu là phát hiện ngoại lệ ngay trong ngày thay vì để dồn đến cuối tháng.
Bao nhiêu đơn được tạo trong ngày?
Số đơn tạo mới cho biết lượng giao dịch mà website tiếp nhận, nhưng chưa phải doanh thu hoàn tất. Kế toán sử dụng chỉ tiêu này làm điểm đầu của phễu đối soát.
Nếu có nhiều đơn trùng, đơn test hoặc spam, hệ thống cần có cơ chế nhận diện để không đẩy sang các bước tiếp theo.
Bao nhiêu đơn đã giao thành công?
Đây là nhóm cần được ưu tiên đối chiếu với kho và hóa đơn. Chênh lệch giữa đơn tạo và đơn giao thành công sẽ được giải thích bởi đơn đang xử lý, hủy hoặc giao thất bại.
Nếu tỷ lệ giao thất bại tăng bất thường, đây cũng là tín hiệu vận hành cần được bộ phận bán hàng kiểm tra.
Bao nhiêu đơn đã lập hóa đơn?
Kế toán cần xác định số đơn thuộc diện phải xử lý hóa đơn và số đã hoàn tất. Những Order ID giao thành công nhưng chưa có liên kết hóa đơn cần được đưa vào danh sách ngoại lệ.
Ngược lại, hóa đơn xuất hiện mà Order ID đang hủy hoặc giao thất bại cũng là trường hợp phải kiểm tra ngay.
Bao nhiêu đơn bị hủy, hoàn hoặc đang treo?
Đơn treo lâu là một trong những nguyên nhân làm số liệu tháng sau khó đối chiếu. Website nên quy định thời hạn tối đa cho từng trạng thái và cảnh báo những đơn không thay đổi trong nhiều ngày.
Đối với đơn hoàn, cần kiểm tra đồng thời hàng đã quay về kho, tiền đã hoàn và hóa đơn đã xử lý chưa.
Tổng tiền website có khớp hóa đơn, COD và ngân hàng không?
Không nhất thiết tất cả nguồn phải bằng nhau ngay trong cùng ngày vì thời điểm thu tiền có thể khác, nhưng mọi chênh lệch phải giải thích được. Ví dụ COD đang chờ chuyển tiền là chênh lệch hợp lý.
Điều đáng lo là khoản chênh không gắn được với Order ID nào. Đó mới là tín hiệu cho thấy dữ liệu đang mất liên kết.
Khi website tăng từ 20 lên 2.000 đơn/ngày – hệ thống hóa đơn phải thay đổi ra sao?
Quy trình phù hợp với 20 đơn mỗi ngày sẽ không thể tiếp tục khi doanh nghiệp đạt 2.000 đơn. Điểm thay đổi quan trọng không chỉ nằm ở tốc độ phát hành hóa đơn mà ở khả năng chuẩn hóa dữ liệu, tự động đối soát và phát hiện ngoại lệ. Khi quy mô tăng, con người không thể kiểm tra từng dòng nhưng vẫn phải kiểm soát được toàn bộ hệ thống.
Giai đoạn 20 đơn/ngày – kế toán còn có thể kiểm tra từng đơn
Ở quy mô nhỏ, kế toán có thể mở từng Order ID, kiểm tra giao hàng và lập hóa đơn. Tuy nhiên, ngay từ giai đoạn này nên hình thành quy tắc đặt mã và lưu dữ liệu.
Nếu phụ thuộc hoàn toàn vào kinh nghiệm một người, doanh nghiệp sẽ gặp khó khăn khi lượng đơn tăng hoặc nhân sự thay đổi.
Giai đoạn 200 đơn/ngày – cần quy tắc xử lý tự động
Hai trăm đơn mỗi ngày đã khiến thao tác nhập lại trở nên tốn thời gian. Đây là lúc doanh nghiệp nên tích hợp website với phần mềm bán hàng, vận chuyển và hóa đơn.
Những đơn bình thường được tự xử lý theo quy tắc, còn kế toán kiểm tra đơn lỗi dữ liệu, hoàn hoặc có chênh lệch.
Giai đoạn 1.000 đơn/ngày – đối soát phải dựa trên dữ liệu
Ở quy mô này, việc mở từng đơn gần như không khả thi. Báo cáo đối soát cần tự động nhóm giao thành công chưa có hóa đơn, hóa đơn không tìm thấy đơn, COD lệch tiền và đơn hoàn chưa xử lý.
Kế toán chuyển từ “làm từng giao dịch” sang “kiểm soát thuật toán và ngoại lệ”.
Giai đoạn bán đa kho, đa kênh – cần chuẩn hóa mã giao dịch
Một sản phẩm có thể xuất từ nhiều kho và đơn có thể đến từ nhiều nền tảng. Nếu mã giao dịch không thống nhất, rủi ro trùng hoặc mất đơn tăng nhanh.
Mỗi đơn cần có nguồn bán, kho xử lý, SKU chuẩn, mã vận chuyển và mã hóa đơn để hệ thống có thể truy ngược xuyên suốt.
Chuyển từ “kế toán nhập liệu” sang “kế toán kiểm soát ngoại lệ”
Tự động hóa không làm mất vai trò kế toán mà thay đổi vai trò. Thay vì nhập 2.000 đơn, kế toán tập trung vào 20 đơn có dấu hiệu bất thường.
Đây là mô hình hiệu quả hơn vì thời gian được dành cho kiểm soát rủi ro, phân tích và xử lý trường hợp phức tạp thay vì lặp lại thao tác nhập dữ liệu.
Câu hỏi thường gặp về hóa đơn điện tử khi bán hàng trên website tại Bắc Ninh
Các câu hỏi về hóa đơn website thường xoay quanh ba vấn đề: khách cá nhân không yêu cầu hóa đơn, COD, hàng trả lại và khả năng tự động hóa. Khi trả lời, cần dựa trên quy định đang có hiệu lực từ ngày 01/7/2026 là Nghị định 254/2026/NĐ-CP cùng các văn bản hướng dẫn, thay vì tiếp tục áp dụng máy móc quy định cũ đã hết hiệu lực.
Bán hàng trên website cho cá nhân có phải lập hóa đơn không?
Về nguyên tắc, khi bán hàng hóa, cung cấp dịch vụ, người bán phải lập hóa đơn điện tử, trừ trường hợp thuộc nhóm pháp luật quy định không phải sử dụng hóa đơn điện tử. Việc người mua là cá nhân không tự động làm mất nghĩa vụ này.
Điểm cần xác định tiếp là doanh nghiệp hoặc hộ kinh doanh đang sử dụng loại hóa đơn nào và nội dung thông tin người mua cần thể hiện ra sao trong trường hợp cụ thể.
Khách không cung cấp thông tin xuất hóa đơn thì xử lý thế nào?
Website cần áp dụng yêu cầu dữ liệu phù hợp với loại hóa đơn và đối tượng người mua. Không nên ép mọi khách cá nhân cung cấp thông tin doanh nghiệp, nhưng cũng không nên vì khách bỏ trống phần “xuất hóa đơn” mà loại luôn giao dịch khỏi hệ thống hóa đơn.
Đối với khách B2B, nên yêu cầu xác nhận thông tin pháp lý trước khi phát hành để giảm việc điều chỉnh sau đó.
Đơn COD nên lập hóa đơn vào thời điểm nào?
Không nên mặc định ngày tiền COD về ngân hàng là ngày lập hóa đơn. Với bán hàng hóa, nguyên tắc hiện hành là thời điểm chuyển giao quyền sở hữu hoặc quyền sử dụng hàng hóa cho người mua, không phân biệt đã thu tiền hay chưa.
Do đó, doanh nghiệp cần đối chiếu trạng thái giao nhận thực tế và quy trình chuyển giao của mình để cấu hình hệ thống.
Khách trả lại hàng sau khi đã có hóa đơn xử lý ra sao?
Theo Thông tư 91/2026/TT-BTC, nếu khách trả lại toàn bộ hoặc một phần hàng hóa, kể cả đổi hàng làm thay đổi giá trị, người bán về nguyên tắc lập hóa đơn điều chỉnh; pháp luật cũng quy định trường hợp có thỏa thuận để người mua lập hóa đơn trả lại. Hồ sơ, chứng từ liên quan đến việc trả lại cần được lưu giữ.
Website vì vậy phải liên kết đơn hoàn với hóa đơn gốc thay vì chỉ cập nhật trạng thái “returned”.
Website có thể tự động lập và gửi hóa đơn cho khách không?
Về kỹ thuật, website có thể tích hợp với phần mềm bán hàng và giải pháp hóa đơn điện tử để truyền dữ liệu và tự động hóa quy trình. Tuy nhiên, điều kiện kích hoạt phải phù hợp quy định về thời điểm lập hóa đơn và hệ thống phải kiểm tra dữ liệu trước khi phát hành.
Tự động hóa hiệu quả nhất khi có cơ chế ngoại lệ, nhật ký và khả năng truy vết, không phải khi mọi đơn đều được phát hành hóa đơn ngay lập tức mà không kiểm tra.
Xây website bán hàng “sẵn sàng cho thuế” ngay từ ngày đầu vận hành
Một website “sẵn sàng cho thuế” không nhất thiết phải là hệ thống đắt tiền nhưng phải có dữ liệu có cấu trúc. Mỗi đơn cần biết nó đến từ đâu, gồm hàng gì, được giao lúc nào, khách thanh toán thế nào, hóa đơn nào liên quan và có phát sinh hoàn hủy hay không. Nếu những nền tảng này được xây từ đầu, doanh nghiệp tại Bắc Ninh có thể mở rộng doanh số mà không biến bộ phận kế toán thành nơi sửa lỗi dữ liệu cuối cùng.
Thiết kế dữ liệu trước rồi mới nghĩ đến tự động hóa
Tự động hóa một quy trình sai chỉ khiến sai nhanh hơn. Trước khi tích hợp hóa đơn, doanh nghiệp cần chuẩn hóa SKU, Order ID, trạng thái đơn, trường thông tin người mua, giảm giá và thanh toán.
Sau khi dữ liệu ổn định mới xác định quy tắc nào được chạy tự động và quy tắc nào cần con người duyệt.
Mỗi đơn hàng phải truy xuất được từ đặt hàng đến hóa đơn
Một Order ID tốt cần trả lời được toàn bộ hành trình: ai đặt, mua gì, kho nào xuất, mã vận đơn nào, khi nào giao, thanh toán bằng gì và số hóa đơn nào liên quan.
Khả năng truy xuất này vừa phục vụ kế toán vừa giúp chăm sóc khách hàng, kiểm soát kho và xử lý tranh chấp nhanh hơn.
Đừng để kế toán cuối tháng mới phát hiện đơn bị thiếu
Nếu cuối tháng mới đối soát, một lỗi tích hợp có thể đã ảnh hưởng hàng nghìn đơn. Kiểm tra hằng ngày giúp phát hiện ngay việc API ngừng đồng bộ, vận chuyển không trả trạng thái hoặc phần mềm hóa đơn chưa nhận dữ liệu.
Website nên có cảnh báo ngoại lệ theo ngày thay vì chỉ có báo cáo doanh thu cuối tháng.
Chuẩn hóa quy trình giữa bán hàng, kho, vận chuyển và kế toán
Bốn bộ phận cần dùng chung định nghĩa về trạng thái đơn. “Hoàn thành” đối với bán hàng, kho và kế toán không nên mang ba ý nghĩa khác nhau.
Khi quy trình thống nhất, dữ liệu tự chạy qua các hệ thống và nhân viên chỉ can thiệp khi có ngoại lệ. Đây là nền tảng để giảm sai sót hóa đơn trong dài hạn.
Giải pháp hỗ trợ thiết lập hóa đơn điện tử cho đơn vị bán hàng online tại Bắc Ninh
Đơn vị bán hàng online tại Bắc Ninh khi triển khai website nên đánh giá đồng thời quy trình bán hàng, phần mềm kế toán, giải pháp hóa đơn điện tử, kho, cổng thanh toán và đơn vị vận chuyển. Việc thiết lập từ đầu giúp xác định đúng nguồn dữ liệu, thời điểm chuyển trạng thái và phương án xử lý đơn hủy, COD hoặc hàng hoàn.
Một giải pháp phù hợp không chỉ hỗ trợ đăng ký và sử dụng hóa đơn điện tử mà còn cần hướng tới mục tiêu lâu dài: giảm nhập liệu, hạn chế sai sót, đối soát nhanh và giúp doanh nghiệp có thể truy xuất từng giao dịch khi cần kiểm tra.
Hóa đơn điện tử khi bán hàng trên website sẽ dễ kiểm soát hơn khi dữ liệu đơn hàng, thanh toán và chứng từ được đồng bộ trong cùng một quy trình. Người bán nên rà soát cả các đơn hủy, hoàn và khuyến mại trước khi chốt doanh thu. Cách quản lý có hệ thống giúp giảm chênh lệch và hỗ trợ công việc kế toán – thuế thuận lợi hơn.
