Tự động đối chiếu ba chiều: bảng dữ liệu và quy trình để giữ thanh toán AP

Vấn đề mà đối chiếu ba chiều thực sự giải quyết

Đối chiếu ba chiều tự động có mục tiêu đơn giản: bạn chỉ thanh toán một hóa đơn khi nó khớp với những gì bạn đã đặt và những gì thực sự nhận được. Ba tài liệu là đơn đặt hàng (PO), biên nhận (receipt) và hóa đơn nhà cung cấp.

Nếu không kiểm tra này, bộ phận kế toán phải trả tiền dựa trên một tài liệu duy nhất có thể sai hoặc thiếu. Nhà cung cấp có thể xuất hóa đơn nhiều hơn số hàng giao, dùng giá khác so với thỏa thuận, hoặc gửi hóa đơn trùng lặp trông như mới trong luồng email.

Những lỗi này hiếm khi trông lớn ngay ngày đầu. Chúng xuất hiện như những chỗ rò nhỏ: một dòng bị tính hai lần, lô hàng thiếu vài đơn vị, tăng giá chưa được duyệt, hoặc phí vận chuyển bị cộng sai. Theo thời gian, những sai sót nhỏ ấy thành tiền thật.

Mục tiêu không phải là “duyệt hóa đơn.” Mục tiêu là chặn thanh toán cho đến khi các trường quan trọng bạn chọn (thường là số lượng, đơn giá và tổng tiền) khớp trên PO, biên nhận và hóa đơn. Khi không khớp, hóa đơn không nên biến mất trong email. Nó phải vào hàng đợi ngoại lệ với mã lý do rõ ràng và các trường khác nhau chính xác.

Đối chiếu ba chiều cũng phân định rõ trách nhiệm giữa các đội. Procurement chịu phần đặt hàng (điều khoản và giá). Receiving xác nhận những gì đã đến (số lượng và ngày). Finance kiểm soát những gì được thanh toán (kiểm tra và phát hành hóa đơn).

Cần đặt kỳ vọng sớm: đây là vấn đề quy trình cộng với dữ liệu, không phải một nút phê duyệt. Nếu dòng PO mơ hồ, biên nhận không được ghi, hoặc hóa đơn không thể liên kết tới dòng PO, tự động hóa sẽ không cứu được bạn.

Tài liệu và vai trò: PO, biên nhận, hóa đơn và ai chịu trách nhiệm gì

Đối chiếu ba chiều chỉ hoạt động khi mỗi tài liệu có một người sở hữu rõ ràng. Nếu “ai cập nhật gì” mơ hồ, hệ thống hoặc chặn những khoản thanh toán hợp lệ hoặc cho qua những khoản xấu.

Mô hình sở hữu thực tế:

• Người yêu cầu (Requester) tạo yêu cầu mua và xác nhận nhu cầu.
• Procurement tạo và duy trì PO (nhà cung cấp, giá, điều khoản).
• Kho/nhân viên nhận hàng (hoặc chủ sở hữu dịch vụ) ghi biên nhận hoặc xác nhận hoàn thành.
• AP/Finance ghi nhận hóa đơn và điều khiển việc thanh toán.

Mỗi tài liệu cũng cần bộ trường tối thiểu để việc đối chiếu không phải đoán mò.

PO (purchase order) cần supplier ID, số PO, các dòng hàng (SKU hoặc dịch vụ), số lượng đặt, đơn giá, tiền tệ, quy tắc thuế và điều khoản thanh toán.

Receipt cần tham chiếu PO, ngày nhận, số lượng nhận theo dòng PO, và người nhận. Với dịch vụ, coi đó là chấp nhận và ghi người duyệt.

Invoice cần số hóa đơn nhà cung cấp, ngày hóa đơn, tham chiếu PO (hoặc cách an toàn để tìm PO), chi tiết dòng (số lượng, đơn giá), thuế/vận chuyển và tổng cộng.

Cũng cần quyết định khi nào chạy đối chiếu. Không nên là sự kiện một lần. Kích hoạt mỗi khi thực tế thay đổi:

1. Khi một hóa đơn được nhập (để quyết ngay trả hay giữ).
2. Khi một biên nhận được đăng (để hóa đơn đang giữ có thể trở thành có thể thanh toán).
3. Khi PO thay đổi (để các hóa đơn mở được kiểm tra lại).

Biên nhận một phần và nhiều hóa đơn là bình thường. Một dòng PO có thể đến trong ba lô và được lập hóa đơn trên hai hóa đơn. Logic của bạn nên so sánh tổng cộng đã nhận vs tổng cộng đã lập hóa đơn theo dòng PO, không chỉ so sánh từng tài liệu riêng lẻ.

Quy tắc cần quyết trước khi bạn xây dựng gì cả

Trước khi chạm vào bảng hay bước quy trình, hãy thống nhất các quy tắc sẽ điều khiển toàn hệ thống. Quy tắc mơ hồ tạo ra thất bại dự đoán được: hệ thống chặn quá nhiều (người ta bỏ qua) hoặc chặn quá ít (vẫn trả những hóa đơn xấu).

Chọn mức đối chiếu. Đối chiếu chỉ ở mức header kiểm tra tổng ở cấp tài liệu. Nghe có vẻ dễ hơn, nhưng nhanh chóng vỡ khi có giao hàng một phần, backorder, dòng phí vận chuyển, hoặc thuế hỗn hợp. Đối chiếu theo dòng tốn thời gian hơn để thiết lập, nhưng an toàn hơn vì bạn so sánh cùng một thứ trên PO, biên nhận và hóa đơn: dòng cụ thể, số lượng và đơn giá.

Định nghĩa chặn cứng (hard blocks) so với cảnh báo. Chặn cứng nghĩa là không thể thanh toán cho đến khi vấn đề được giải quyết. Cảnh báo nghĩa là hóa đơn có thể tiến nhưng ai đó phải thừa nhận rủi ro.

Điểm khởi đầu điển hình:

• Chặn cứng: số lượng lập hóa đơn vượt số lượng đã nhận (với hàng hóa).
• Chặn cứng: đơn giá vượt giá PO vượt mức dung sai.
• Cảnh báo: khác lệch làm tròn nhỏ.
• Cảnh báo: khác biệt về thuế hoặc vận chuyển nếu được kỳ vọng và mã hóa riêng.

Giữ các quy tắc dung sai rõ ràng. Định nghĩa phương pháp (phần trăm, số tiền tuyệt đối, hoặc cao hơn trong hai cái) và ai sở hữu. Ví dụ: cho phép +/- 1% hoặc +/- $5 mỗi dòng, với finance được phép thay dung sai chỉ khi có ghi chú kiểm toán.

Sử dụng một tập trạng thái nhỏ, dùng chung. Tránh trạng thái tuỳ biến cho từng đội. Một tập sạch thường là đủ: Matched, Hold, Exception, Approved. "Hold" nghĩa là thanh toán bị chặn. "Exception" nghĩa là cần người xem xét. "Approved" nghĩa là người cụ thể đã chấp nhận khác biệt và ghi lý do.

Mô hình dữ liệu: các bảng bạn cần (và tại sao)

Đối chiếu ba chiều chỉ hoạt động nếu mô hình dữ liệu có thể căn hàng một dòng PO, những gì đã nhận và những gì đã được lập hóa đơn. Mỗi dòng hóa đơn nên có thể khớp với một dòng PO cụ thể (hoặc được đánh dấu rõ là non-PO), và mỗi dòng biên nhận nên giảm số lượng còn lại trên dòng PO đó.

Bắt đầu với các bảng mua hàng cốt lõi:

• Vendors: một hàng cho mỗi nhà cung cấp (tên, điều khoản, thông tin thuế).
• ItemsServices: tuỳ chọn, nhưng giúp nhất quán (SKU, mô tả, đơn vị đo).
• PurchaseOrders: header PO (vendor_id, currency, requested_by, status).
• PO_Lines: mỏ neo để đối chiếu (po_id, item_id/description, ordered_qty, unit_price).

Receiving cần bản ghi riêng, ngay cả khi một "biên nhận" chỉ là xác nhận. Giữ biên nhận tách khỏi hóa đơn để bạn có bằng chứng về những gì đến và khi nào:

• Receipts: header biên nhận (vendor_id, received_date, location, status).
• Receipt_Lines: mỗi dòng tham chiếu tới PO line (receipt_id, po_line_id, received_qty, notes).

Invoicing phản chiếu receiving. Lưu những gì nhà cung cấp đã tính theo dòng và nối tới PO line bảo phủ nó:

• Invoices: header hóa đơn (vendor_id, invoice_number, invoice_date, due_date, status).
• Invoice_Lines: (invoice_id, po_line_id khi có, invoiced_qty, unit_price, tax, line_total).

Cuối cùng, tạo một bản ghi hướng tới thanh toán mà workflow có thể chặn. Một số đội gọi đó là bill, payment request hoặc pay run item:

• PaymentRequests (hoặc Bills): liên kết tới invoice_id và bao gồm payment_hold (true/false) cùng hold_reason.

Để phục vụ kiểm toán và xử lý ngoại lệ sạch, thêm các trường lifecycle nhất quán trên các header (POs, receipts, invoices, payments): status, created_at/created_by, approved_at/approved_by, posted_at, và (tuỳ chọn) source_document_id cho các import.

Các trường và quan hệ then chốt giúp đối chiếu tin cậy

Đối chiếu hiệu quả nhất khi mọi tài liệu truy vết về cùng một dòng mục. Điều đó nghĩa là ID ổn định, liên kết rõ ràng và tổng có thể tính lại từ các dòng.

Đảm bảo mỗi bảng có cả ID nội bộ ổn định và số ngoài mà người dùng tìm kiếm:

• PO header: po_id, po_number, vendor_id, currency, status, po_date
• PO lines: po_line_id, po_id, item_id or description, ordered_qty, unit_price, tax_rate, line_total
• Receipts: receipt_id, receipt_number, vendor_id, received_date; receipt_line_id, receipt_id, po_line_id, received_qty
• Invoices: invoice_id, vendor_id, vendor_invoice_number, invoice_date, currency, subtotal, tax_total, total; invoice_line_id, invoice_id, po_line_id, qty, unit_price, tax_amount, line_total
• Vendors and items: vendor_id, payment_terms, default_currency; item_id, uom, tax_code

Các liên kết quan trọng nhất là ở mức dòng:

• invoice_line.po_line_id nên trỏ tới PO line.
• receipt_line.po_line_id nên trỏ đến cùng PO line đó.

Đây là điều cho phép bạn so sánh số lượng và giá mà không phải đoán.

Để xử lý lô hàng một phần, tính tổng chạy cho mỗi dòng PO: received_qty (tổng các receipt lines) và invoiced_qty (tổng các invoice lines). Sau đó tính remaining_qty = ordered_qty - received_qty và open_to_invoice_qty = received_qty - invoiced_qty. Những giá trị này làm rõ liệu hóa đơn là tới sớm, trễ hay lập hóa đơn vượt.

Đừng ghi đè lịch sử khi PO thay đổi. Lưu số phiên PO và hoặc giữ các PO lines cũ (với cờ active) hoặc ghi log thay đổi (ai thay đổi gì, khi nào, giá trị cũ, giá trị mới).

Thêm các cơ chế bảo vệ cơ bản để ngăn trùng lặp và liên kết sai:

• Unique (vendor_id, vendor_invoice_number)
• Unique receipt_number và po_number
• Not null trên currency, quantities và unit_price
• Check constraints như qty >= 0 và unit_price >= 0
• Foreign keys từ invoice_line và receipt_line tới po_line

Quy trình từng bước: từ nhập hóa đơn đến giữ thanh toán

Đối chiếu ba chiều thường có ba điểm nhập: hóa đơn đến (email, upload, EDI), một biên nhận được đăng, hoặc PO thay đổi (giá, số lượng, trạng thái). Workflow nên phản ứng với bất kỳ thay đổi nào để một hóa đơn có thể rời trạng thái giữ ngay khi phần còn thiếu xuất hiện.

1. Xác thực các thông tin cơ bản của hóa đơn trước. Xác nhận nhà cung cấp còn hoạt động, PO tồn tại, tiền tệ khớp PO, và tổng toán học trong hóa đơn nhất quán (tổng các dòng cộng ra đúng, thuế hợp lý, không có số âm trừ khi hỗ trợ credit). Nếu không đạt, đưa hóa đơn trực tiếp vào Hold với lý do rõ ràng.

2. Đối chiếu theo dòng, không chỉ ở header. Với mỗi dòng hóa đơn, tìm dòng PO tương ứng và tổng biên nhận đến thời điểm đó. So sánh:

• Số lượng lập hóa đơn vs số lượng đã nhận (hoặc đã nhận trừ đã lập hóa đơn trước đó)
• Đơn giá lập hóa đơn vs đơn giá trên PO
• Quy tắc dung sai
• Dòng PO còn mở để lập hóa đơn hay không

3. Thiết lập trạng thái và thi hành chặn. Một mẫu phổ biến:

• Matched: tất cả các dòng vượt qua kiểm tra, không còn ngoại lệ.
• Hold: ít nhất một dòng fail, hoặc dữ liệu bắt buộc thiếu.

Khi đặt Hold, tạo một bản ghi payment hold mà quy trình thanh toán phải tôn trọng. Giữ các hold tách khỏi hóa đơn để holds có thể thêm, giải phóng hoặc thay thế mà không sửa lịch sử hóa đơn.

4. Ghi mã lý do mà finance có thể tin cậy. Tránh chỉ dùng text tự do. Dùng các mã như PRICE_OVER_TOLERANCE, QTY_NOT_RECEIVED, PO_CLOSED, VENDOR_MISMATCH, hoặc CURRENCY_MISMATCH, kèm một ghi chú ngắn.

Thiết kế hàng đợi ngoại lệ cho finance (lưu gì và hiển thị gì)

Hàng đợi ngoại lệ là nơi đối chiếu trở nên hữu dụng, không chỉ nghiêm ngặt. Finance nên thấy chỉ những hóa đơn cần quyết định, với đủ bối cảnh để quyết nhanh và để lại hồ sơ kiểm toán rõ ràng.

Cách phổ biến là có bảng riêng như ExceptionCases. Mỗi hàng đại diện cho một hóa đơn bị chặn (hoặc một dòng hóa đơn) và trỏ lại tới invoice, PO, và receipt. Giữ engine đối chiếu ở chế độ chỉ đọc tại đây. Hàng đợi dành cho quyết định và ghi chép.

Những gì nên lưu trong ExceptionCases:

Lưu những gì sai, mức độ, ai sở hữu và bước tiếp theo:

• Type (missing receipt, price variance, quantity variance, PO not found, duplicate invoice)
• Severity (info, warning, block) cùng lý do hiển thị thân thiện
• Owner (người hoặc đội) và status (open, waiting on vendor, waiting on warehouse, resolved, overridden)
• Snapshot biến động dưới dạng số có thể sắp xếp (invoice amount, matched amount, price delta, quantity delta)
• Trường SLA (due date, escalation flag, reassigned_at, reassignment_reason)

Cũng lưu dữ liệu cộng tác và kiểm toán: comments (tác giả, dấu thời gian) và metadata file đính kèm (tên file, loại, uploaded_by, uploaded_at). Dù file lưu ở nơi khác, metadata nên nằm trong case để lịch sử còn nguyên.

Những gì finance nên thấy (và làm):

Giao diện hàng đợi nên là một danh sách công việc gọn: vendor, số hóa đơn, loại ngoại lệ, mức độ, số tiền, ngày đáo hạn, người chịu trách nhiệm, và một thông điệp “tại sao bị chặn” rõ ràng.

Mở một case nên hiển thị tóm tắt song song: các dòng PO, số lượng đã nhận, dòng hóa đơn, và các trường sai chính xác.

Giữ các hành động giới hạn và an toàn:

• Yêu cầu biên nhận (route đến receiving, đặt trạng thái chờ)
• Yêu cầu credit memo (gửi tới nhà cung cấp, ghi nhận điều chỉnh dự kiến)
• Phê duyệt ghi đè (yêu cầu lý do, ghi người duyệt và dấu thời gian)
• Chuyển giao (cập nhật owner, giữ lịch sử chuyển giao)
• Đóng khi đã giải quyết (chỉ sau khi thay đổi khiến đối chiếu thành công)

Ví dụ: một hóa đơn bị chặn vì đã nhận 8 đơn vị nhưng lập hóa đơn 10 đơn vị. Finance có thể yêu cầu hóa đơn sửa, hoặc chấp thuận ghi đè cho 8 đơn vị đã nhận và giữ 2 đơn vị còn lại.

Ví dụ thực tế: biên nhận một phần và hóa đơn không khớp

Người mua tạo PO 100 đơn vị mặt hàng A, đơn giá $10. PO tổng $1,000. Hai ngày sau, kho ghi biên nhận 80 đơn vị.

Sau đó một hóa đơn cho 100 đơn vị được gửi tới, đơn giá $10 mỗi cái. Việc đối chiếu nên so sánh dòng hóa đơn với những gì đã nhận, không chỉ với số đã đặt.

Trên dòng đó:

• Đặt: 100 đơn vị
• Đã nhận: 80 đơn vị
• Lập hóa đơn: 100 đơn vị
• Số lượng khớp: min(Received, Invoiced) = 80 đơn vị
• Số lượng không khớp: Invoiced - Matched = 20 đơn vị

Hóa đơn trở thành “On hold” vì 20 đơn vị không có biên nhận. Finance thấy một case với lý do rõ (Quantity variance: +20) và các số chính đối chiếu cạnh nhau.

Thông báo nên gửi tới người có thể sửa nhanh nhất: thường là người nhận (để xác nhận biên nhận có thiếu) và người mua (để theo dõi nếu lô hàng thực sự thiếu).

Khi 20 đơn vị còn lại về, kho đăng một biên nhận thứ hai cho 20 đơn vị. Hệ thống chạy lại đối chiếu: received = 100, unmatched = 0, hóa đơn chuyển thành Matched và hold được giải phóng.

Thêm biến thể giá: nếu nhà cung cấp lập hóa đơn 100 đơn vị với $10.50 thay vì $10.00, số lượng khớp nhưng giá thì không. Kết quả mong đợi: giữ hóa đơn và chuyển với lý do “Price variance: +$0.50/unit (+$50 total).”

Những lỗi phổ biến làm vỡ workflow đối chiếu ba chiều

Hầu hết thất bại không phải do toán học. Chúng đến từ liên kết dữ liệu yếu và kiểm soát lỏng lẻo trên các tài liệu đã đăng.

Matching chỉ ở tổng hóa đơn. Header có thể trông ổn trong khi một dòng bị tính quá hoặc thiếu. Hãy đối chiếu theo dòng, và rõ ràng về những gì có thể khác (thường là phí vận chuyển) và những gì không thể (số lượng nhận và đơn giá).

Giả định chỉ có một biên nhận và một hóa đơn cho mỗi PO. Mua sắm thực tế có giao hàng tách nhiều lần và lập hóa đơn nhiều lần. Hỗ trợ nhiều biên nhận và nhiều hóa đơn trên cùng dòng PO, và theo dõi số lượng còn mở theo dòng.

Cho phép chỉnh sửa biên nhận hoặc hóa đơn đã đăng mà không có dấu vết. Nếu ai đó có thể thay đổi im lặng, đối chiếu mất giá trị bằng chứng. Khóa các bản ghi đã đăng và sửa bằng chứng từ điều chỉnh giữ lịch sử.

Thiếu ngăn chặn trùng lặp. Cùng một số hóa đơn nhà cung cấp có thể được nhập hai lần, hoặc PDF bị tải lên lại. Thêm ràng buộc duy nhất sớm (vendor + invoice number, và tuỳ chọn ngày/số tiền) và hiển thị thông báo rõ khi phát hiện trùng lặp.

Lý do ngoại lệ mơ hồ. Finance không nên phải đoán. Dùng mã lý do rõ ràng để định tuyến: price mismatch, quantity mismatch, missing receipt, duplicate suspected, PO not found, vendor mismatch.

Bảng kiểm nhanh trước khi bật chặn thanh toán

Chặn thanh toán là lúc đối chiếu không còn là báo cáo mà trở thành kiểm soát. Nếu những cơ bản không chắc, bạn sẽ tạo nhiễu cho finance và thanh toán trễ cho nhà cung cấp.

Thử một tập nhỏ hóa đơn khác nhau: một cái khớp sạch, một biên nhận một phần, một thay đổi giá và một khác biệt thuế. Nếu bất kỳ cái nào không thể đối chiếu sạch, sửa dữ liệu và quy tắc trước.

Checklist:

• Reference completeness: mỗi hóa đơn có vendor và tham chiếu PO, và mỗi dòng hóa đơn có thể map tới một dòng PO cụ thể (không chỉ “tổng PO”). Quyết định xử lý khi nhà cung cấp chỉ gửi số header PO.
• Consistent math: số lượng, đơn giá và tổng được tính lại cùng một cách mỗi lần. Rõ ràng về thuế, vận chuyển, chiết khấu và làm tròn (ví dụ làm tròn theo dòng vs chỉ ở tổng hóa đơn).
• Statuss chặn đủ sớm: đặt “on hold” trước khi bất kỳ payment request hay bản ghi thanh toán nào được tạo.
• Structured exceptions: mỗi hold lưu mã lý do và owner (AP, buyer, receiver). Thêm ngày đáo hạn để holds không nằm mãi.
• Real audit trail: các ghi đè ghi ai duyệt, khi nào và phê duyệt gì (bao gồm giá trị gốc). Nếu cho phép chỉnh sửa, log giá trị trước và sau.

Bước tiếp theo: triển khai thử và xây dựng trực quan

Xem tự động hóa đối chiếu ba chiều như một kiểm soát: chứng minh nó hoạt động trên một phần nhỏ chi tiêu, sau đó triển khai rộng.

Bắt đầu với pilot dễ theo dõi. Chọn một đơn vị kinh doanh, một nhóm nhà cung cấp nhỏ gửi hóa đơn sạch, hoặc một hạng mục hàng hóa. Giữ quy tắc nghiêm ngặt ban đầu (khớp chính xác số lượng và giá) để lỗi dữ liệu xuất hiện nhanh.

Đo lường thành công bằng một góc nhìn finance đơn giản: số holds mỗi tuần, mã lý do hàng đầu, thời gian từ hold tới giải phóng, bao nhiêu hold là sai khớp thực sự, và nhà cung cấp nào tạo ngoại lệ lặp lại.

Nếu muốn prototype nhanh, nền tảng no-code có thể giúp vì bạn mô hình bảng, quy tắc đối chiếu và luồng mà không viết mã. Ví dụ, trong AppMaster (appmaster.io) bạn có thể xây các bảng PO, receipt, invoice và exception, sau đó nối logic giữ bằng một business process trực quan để cùng quy tắc chạy trên mọi trigger.

Thử với hóa đơn thực từ nhóm pilot, bao gồm biên nhận một phần và sai sót nhà cung cấp phổ biến. Mong phải tinh chỉnh khoá đối chiếu và thêm dung sai nhỏ chỉ sau khi thấy mẫu. Khi các hold hợp lý và thời gian giải quyết cải thiện, mở rộng phạm vi và thêm quy tắc phong phú hơn (xử lý thuế và phí vận chuyển, chuyển đổi đơn vị đo, lô hàng tách) mà không mất kiểm soát cốt lõi: không phát hành thanh toán cho tới khi đối chiếu được dọn sạch.