17 thg 5, 2025·7 phút đọc

Cổng hạn mức tín dụng cho đơn hàng B2B và điều khoản thanh toán theo từng khách hàng

Thiết lập hạn mức và điều khoản cho từng khách hàng, rồi tự động hóa cổng hạn mức tín dụng cho đơn hàng B2B để tạm giữ các đơn rủi ro và chuyển chúng để xét duyệt.

Cổng hạn mức tín dụng giải quyết vấn đề gì (nói dễ hiểu)

Đơn hàng B2B có thể trông ổn trên giấy tờ nhưng vẫn gây ra khủng hoảng tiền mặt. Khác với thanh toán bằng thẻ, nhiều khách hàng doanh nghiệp thanh toán sau. Nếu bạn tiếp tục giao hàng trong khi các hóa đơn dồn lên, một người trả chậm có thể âm thầm chiếm một phần lớn vốn lưu động của bạn.

Cổng hạn mức tín dụng là một kiểm tra an toàn đơn giản trước khi một đơn được chấp nhận hoàn toàn. Nó so sánh những gì khách hàng đang nợ (và những gì họ sắp nợ) với hạn mức tín dụng đã thỏa thuận. Nếu đơn mới sẽ đẩy họ vượt quá hạn mức, hệ thống không từ chối đơn vĩnh viễn. Nó tạm giữ đơn để xét duyệt.

Tạm giữ đơn thường có nghĩa là đơn được ghi lại nhưng các bước then chốt bị chặn cho đến khi ai đó phê duyệt. Bạn vẫn có thể xác nhận chi tiết với người mua, và có thể giữ kho nếu đó là chính sách của bạn. Điều bạn thường không làm là giao hàng, lập hóa đơn, hoặc cấp kho vĩnh viễn cho đến khi tạm giữ được gỡ bỏ.

Điều khoản thanh toán thay đổi rủi ro vì chúng quyết định tiền của bạn bị giữ trong bao lâu. Trả trước là rủi ro thấp vì tiền đến trước. Net 30 có thể ổn nếu chi tiêu vẫn trong hạn mức và hóa đơn được trả đúng hạn. Net 60 (hoặc điều khoản tùy chỉnh) làm tăng phơi bày trong thời gian dài hơn.

Một cổng cũng giảm sự nhầm lẫn giữa các bộ phận vì nó biến câu hỏi “chúng ta có thể giao hàng không?” thành một trạng thái rõ ràng, nhất quán cho sales, finance và ops.

Định nghĩa những gì lưu trên mỗi khách hàng (hạn mức, điều khoản, phơi bày)

Cổng chỉ hoạt động nếu hồ sơ khách hàng chứa vài trường mà quy tắc backend có thể tin tưởng. Giữ danh sách ngắn và làm cho mỗi giá trị dễ giải thích.

Bắt đầu với hạn mức tín dụng: số tiền giới hạn và tiền tệ định nghĩa. Nếu bạn bán bằng nhiều tiền tệ, chọn một quy tắc và tuân theo nó. Hoặc quy đổi mọi thứ về một tiền tệ cơ sở trước khi so sánh, hoặc lưu hạn mức theo từng tiền tệ.

Tiếp theo, lưu điều khoản thanh toán dưới dạng dữ liệu có cấu trúc, không phải văn bản tự do. Dùng một loại rõ ràng (Prepay, COD, Net 15, Net 30, Net 60) và lưu số ngày net khi cần. Bằng cách đó logic đơn hàng của bạn có thể phân nhánh mà không phải đoán.

Một bộ trường thực tế cho từng khách hàng có thể bao gồm:

Hạn mức tín dụng và tiền tệ
Loại điều khoản thanh toán và số ngày net (nếu có)
Số tiền override tạm thời (tuỳ chọn) kèm thời hạn hết hạn
Ghi chú override (lý do được cấp và bởi ai)
Công tắc tạm giữ thủ công (nút “dừng”)

Định nghĩa “phơi bày” theo cách khớp với cách bạn thực tế chịu rủi ro. Nhiều đội bao gồm hóa đơn chưa thanh toán cộng với các đơn mở chưa được trả, và đôi khi cả lô hàng đang chờ nếu bạn lập hóa đơn sau khi giao.

Cuối cùng, giữ một tập nhỏ trạng thái đơn để tạm giữ hiển thị rõ và có thể hành động. Ví dụ: Đã duyệt, Đang tạm giữ, Đã phát hành, Đã huỷ.

Mô hình dữ liệu bạn cần cho hạn mức, điều khoản và tạm giữ đơn

Mô hình dữ liệu của bạn nên giúp trả lời dễ dàng ba câu hỏi: ai đang mua, trên điều khoản nào, và họ đã nợ bao nhiêu.

Bắt đầu với một bản ghi Khách hàng mang các đầu vào quyết định: hạn mức tín dụng, điều khoản thanh toán mặc định, và chính sách tạm giữ (ví dụ, tự động tạm giữ khi vượt hạn mức, cho phép nhưng gắn cờ, hoặc chặn thanh toán).

Đơn hàng nên lưu cả kích hoạt và kết quả. Lưu phương thức thanh toán, tổng đơn, và một trạng thái có thể biểu diễn “Đang tạm giữ” mà không lẫn với “Đang chờ”. Thêm lý do tạm giữ để mọi người biết phân biệt giữa “vượt hạn mức” và vấn đề khác (như xác thực địa chỉ).

Một schema tối thiểu thường gồm:

Khách hàng: credit_limit, payment_terms_code, hold_policy, credit_status
Đơn hàng: total_amount, payment_method, status, hold_reason, held_at
Hóa đơn / AR: invoice_total, open_balance, due_date, status (open/paid/void)
Override tín dụng: customer_id, override_amount_or_limit, expires_at, approved_by
Nhật ký kiểm toán: entity_type, entity_id, changed_fields, changed_by, changed_at, note

Để tính phơi bày chính xác, bạn cần dữ liệu nhận phải thu (hóa đơn hoặc đồng bộ bên ngoài) để số dư chưa thanh toán không bị ước chừng từ đơn. Nếu bạn chưa có module lập hóa đơn, lưu một ảnh chụp “số dư mở” trên khách hàng và cập nhật từ các khoản thanh toán đã ghi sổ.

Giữ các override trong một bảng riêng. Điều này tránh việc sửa lộn xộn vào hạn mức chính và cho bạn một chuỗi phê duyệt.

Cách tính phơi bày tín dụng và hạn mức khả dụng

Phép toán cần được thống nhất và viết ra, rồi dùng nhất quán trong ứng dụng và báo cáo tài chính.

Một nền tảng phổ biến là:

Phơi bày tín dụng = hóa đơn chưa thanh toán + giá trị đơn mở

Rồi:

Hạn mức khả dụng = hạn mức tín dụng - phơi bày tín dụng

Trước khi triển khai, định nghĩa rõ “giá trị” nghĩa là gì. Nhiều đội dùng tổng sản phẩm trừ giảm giá, rồi quyết explicit có nên tính thuế và vận chuyển hay không. Nếu bạn tính thuế và vận chuyển, các tạm giữ sẽ kích hoạt sớm hơn. Nếu không tính, bạn có rủi ro duyệt đơn nhưng khi hóa đơn hoàn tất thì vượt hạn mức.

Một vài điều chỉnh giúp tránh bất ngờ:

Thanh toán một phần chỉ giảm hóa đơn chưa thanh toán khi tiền mặt thực sự được ghi nhận (không phải khi thanh toán mới được khởi tạo).
Ghi nợ/hoàn tiền chỉ giảm phơi bày khi được phát hành và phê duyệt để sử dụng.
Đơn bị huỷ nên lập tức loại khỏi giá trị đơn mở.
Trả hàng thường giảm phơi bày sau khi credit note được phê duyệt, không phải lúc yêu cầu trả hàng được tạo.

Thời điểm quan trọng ngang với công thức. Chọn các điểm cập nhật rõ ràng để số liệu dự đoán được:

Khi tạo đơn hoặc khi đơn được duyệt (chọn một và nhất quán)
Khi phát hành hóa đơn (chuyển giá trị từ đơn mở sang hóa đơn chưa thanh toán)
Khi ghi nhận thanh toán (giải phóng phơi bày)

Nếu bạn bán bằng nhiều tiền tệ, quy đổi phơi bày sang tiền tệ hạn mức của khách bằng tỷ giá nhất quán (ví dụ tỷ giá ngày của ngày lập hóa đơn). Nếu bạn hỗ trợ tài khoản cha/con, quyết hạn mức là theo pháp nhân hay chia sẻ trong nhóm, và hiển thị điều đó trên hồ sơ khách hàng.

Bước từng bước: xây quy tắc backend giữ đơn

Build a credit hold flow

Mô hình hóa khách hàng, hóa đơn và đơn hàng, rồi thêm quy tắc tạm giữ hạn mức bằng logic backend trực quan.

Build Now

Cổng hoạt động tốt nhất khi nó chạy tự động mỗi khi một đơn được tạo hoặc thay đổi.

Lưu đơn ở dạng nháp trước, ngay cả khi người mua gửi một cú nhấp. Ghi lại customer ID, tổng đơn, tiền tệ, và một ảnh chụp điều khoản thanh toán để các chỉnh sửa sau này vào hồ sơ khách không thay đổi lịch sử.
Lấy phơi bày hiện tại của khách (theo định nghĩa của bạn). Tính phơi bày dự kiến bằng cách cộng tổng đơn mới.
Áp một quyết định đơn giản:

Nếu phơi bày dự kiến nằm trong hạn mức, đánh dấu đơn là Đã duyệt.
Nếu phơi bày dự kiến vượt hạn mức, đặt đơn sang Đang tạm giữ.

Khi tạm giữ đơn, ghi lại các chi tiết giúp giải thích quyết định sau này:

Lý do tạm giữ (ví dụ "Vượt hạn mức tín dụng $2,450")
Chủ sở hữu hành động tiếp theo (ví dụ "bộ phận AR" hoặc một quản lý cụ thể)
Một bản ghi kiểm toán với các đầu vào đã dùng (hạn mức thời điểm đó, thành phần phơi bày, ai kích hoạt kiểm tra, dấu thời gian)

Kiểm tra lại phơi bày khi có các sự kiện làm thay đổi số, không chỉ khi tạo. Các kích hoạt phổ biến là sửa đơn thay đổi tổng, giao hàng (nếu chính sách của bạn coi giao hàng là cam kết), lập hóa đơn và ghi nhận thanh toán.

Phê duyệt và thông báo để các đơn bị tạm giữ không bị kẹt

Một tạm giữ chỉ có ích nếu dẫn tới quyết định nhanh và có thể theo dõi.

Định nghĩa rõ ai có quyền gỡ tạm giữ. Nhiều đội dùng finance cho quyết định tín dụng và một quản lý sales làm phương án khẩn cấp. Làm rõ bằng vai trò và quyền, và luôn ghi lại ai phê duyệt (hoặc từ chối) và lý do.

Những gì nên hiển thị trên màn hình phê duyệt

Giữ màn hình ngắn, nhưng bao gồm các con số mà người phê duyệt cần:

Hạn mức tín dụng, phơi bày hiện tại, hạn mức khả dụng
Tổng đơn và mức vượt hạn còn bao nhiêu
Điều khoản thanh toán đang lưu và điều khoản yêu cầu (nếu khác)
Một vài ghi chú trạng thái khách (ví dụ, "tài khoản mới" hoặc "đã quá hạn một lần")
Trường bình luận bắt buộc

Sau quyết định, ghi một mục nhật ký phê duyệt (ID đơn, quyết định, người phê duyệt, dấu thời gian, bình luận). Đây là dấu vết kiểm toán và giúp giải thích chậm trễ.

Thông báo và giới hạn thời gian

Thông báo cho người phù hợp ngay khi đơn bị tạm giữ qua kênh mà đội thực sự đọc (email, SMS, hoặc Telegram). Thêm nhắc và leo thang để tạm giữ không nằm im. Một mô hình thực tế là nhắc sau 2 giờ, leo thang sau 24 giờ, và tự huỷ sau 72 giờ nếu không ai xử lý.

Nếu việc gỡ hoàn toàn quá rủi ro, cho phép gỡ có điều kiện (giao một phần, yêu cầu đặt cọc, điều khoản ngắn hơn) và ghi rõ điều kiện để fulfilment và lập hóa đơn làm theo cùng một kế hoạch.

Luồng vận hành: chuyện gì xảy ra sau khi đơn bị tạm giữ

Set up hold approvals

Tạo màn hình phê duyệt "On hold" rõ ràng với vai trò, bình luận và dấu vết kiểm toán.

Start Building

Xử lý đơn bị tạm giữ như đơn bình thường với một khác biệt rõ ràng: nó không thể tiến lên cho đến khi tạm giữ được giải quyết.

Sales, ops và finance đều nên thấy cùng một tín hiệu tạm giữ. Dùng trạng thái như “Đang tạm giữ tín dụng” kèm trường lý do (ví dụ, “Phơi bày vượt hạn mức $1,240”). Thêm một ghi chú nội bộ ngắn để mọi người không phải đoán.

Quy tắc kho nên nghiêm ngặt: các đơn đang tạm giữ không được lấy, đóng gói hay cấp kho. Nếu bạn dự trữ hàng, chỉ dự trữ sau khi gỡ hoặc dùng cửa sổ dự trữ ngắn để đơn tạm giữ không chặn các đơn đã thanh toán.

Với giao tiếp cho khách, giữ lời nhắn trung tính và thực tế, kèm bước tiếp theo rõ ràng. Ví dụ:

“Đơn hàng của bạn tạm thời bị tạm dừng để kiểm tra tài khoản định kỳ. Vui lòng phản hồi để xác nhận thời gian thanh toán, hoặc yêu cầu giao một phần.”
“Chúng tôi có thể giao ngay khi nhận thanh toán hoặc khi hạn mức được điều chỉnh. Phương án nào phù hợp?”
“Chúng tôi có thể tách đơn và giao những mặt hàng nằm trong hạn mức khả dụng.”

Khi thanh toán đến, chọn giữa tự động gỡ và gỡ thủ công. Tự động gỡ phù hợp khi thanh toán hay khớp hóa đơn đáng tin cậy. Gỡ thủ công an toàn hơn khi thanh toán một phần hoặc không rõ. Một thỏa hiệp phổ biến là tự động gỡ chỉ khi thanh toán phủ kín toàn bộ số dư quá hạn; nếu không thì chuyển sang finance.

Theo dõi vài chỉ số để cổng hoạt động tốt: số đơn bị tạm giữ, tỷ lệ được gỡ trong 24 giờ, thời gian trung bình để gỡ, và các lý do tạm giữ hàng đầu.

Ví dụ kịch bản: đơn hàng bán buôn vượt ngưỡng

Deploy your order app

Triển khai hệ thống đơn hàng lên cloud hoặc xuất source code khi bạn cần toàn quyền kiểm soát.

Deploy App

Một khách bán buôn, BrightSide Supplies, có điều khoản Net 30 và hạn mức tín dụng 50,000.

Hóa đơn chưa thanh toán của họ tổng là 38,000. Họ đặt một đơn mới 15,000.

Phơi bày dự kiến là 38,000 + 15,000 = 53,000. Vì 53,000 vượt 50,000, đơn được đặt vào trạng thái tạm giữ và chuyển tới finance để xem xét. Sales vẫn nhìn thấy đơn, nhưng đơn không được đóng gói, giao hay lập hóa đơn cho đến khi rủi ro giảm.

Finance thường có vài tùy chọn: yêu cầu đặt cọc để phơi bày giảm dưới hạn mức, giảm đơn để vừa với hạn mức khả dụng, hoặc phê duyệt override tạm thời với ngày hết hạn và ghi chú lý do.

Checklist nhanh trước khi bật tính năng

Trước khi bật cổng trên môi trường production, làm một lượt kiểm tra ngắn. Vài giờ test có thể tiết kiệm nhiều ngày dọn dẹp sau này.

Bắt đầu với bộ thử nhỏ, đa dạng (5–10 khách): một khách Net 30 và hạn mức thấp, một khách hạn mức cao, một khách trả trước, một khách có nhiều hóa đơn mở, và một khách thường sửa đơn sau khi checkout.

Xác minh hai điều:

Toán học phơi bày khớp mong đợi của kế toán (bao gồm những gì tính và không tính).
Quy tắc tạm giữ chạy vào đúng thời điểm: khi tạo đơn và mọi chỉnh sửa làm tăng phơi bày (thay đổi số lượng, thay đổi giá, thêm vận chuyển, gỡ giảm giá).

Đi qua một đơn bị tạm giữ từ đầu đến cuối và xác nhận lý do tạm giữ rõ ràng, giao hàng và lập hóa đơn hoạt động đúng như dự định, thông báo đến đúng người, và đảo thanh toán có thể tái tạm giữ (hoặc gắn cờ) an toàn.

Những lỗi phổ biến và cách tránh

Add recheck triggers

Kiểm tra lại phơi bày khi có chỉnh sửa, khi lập hóa đơn và khi có thanh toán để các phê duyệt luôn nhất quán.

Set Rules

Hầu hết vấn đề không phải kỹ thuật. Chúng xảy ra khi quy tắc kiểm tra số sai, hoặc khi mọi người học được cách tránh quy tắc.

Các điểm hỏng hay gặp:

Coi toàn bộ tổng đơn là “phơi bày” thay vì chỉ các khoản chưa thanh toán và các khoản cam kết.
Bỏ qua các đơn đã được duyệt nhưng chưa giao, cho phép khách đặt vài đơn lớn trong một ngày trước khi có bất kỳ hóa đơn nào tồn tại.
Cho phép chỉnh sửa thay đổi tiền sau khi duyệt mà không kiểm tra lại hạn mức.
Cho phép override mà không có dấu vết kiểm toán rõ ràng.
Thêm quá nhiều ngoại lệ khiến cổng trở nên tuỳ ý.

Giữ phòng ngừa đơn giản: định nghĩa phơi bày trong một câu, chạy lại cổng khi có bất kỳ chỉnh sửa thay đổi tiền, yêu cầu lý do và người phê duyệt cho override, và giữ các loại ngoại lệ ngắn.

Bước tiếp theo: triển khai cổng trong ứng dụng đơn hàng và lặp nhanh

Bắt đầu với phiên bản nhỏ nhất ngăn rủi ro thực sự: “Nếu phơi bày sau đơn này vượt hạn mức của khách, đặt đơn vào trạng thái Đang tạm giữ.” Chạy trong một tuần, rồi chỉ thêm ngoại lệ khi bạn có thể đặt tên rõ ràng cho chúng (ví dụ, override tạm thời được finance phê duyệt).

Nếu bạn xây ứng dụng đơn hàng mà không muốn viết code tay, AppMaster (appmaster.io) có thể là một lựa chọn thực tế: bạn có thể mô hình hóa khách hàng, đơn hàng, hóa đơn và override một cách trực quan, rồi triển khai logic tạm giữ như một quy trình backend tính toán lại phơi bày khi tạo, sửa, lập hóa đơn và khi có thanh toán.

Giữ bản phát hành đầu tiên nhàm chán và dễ dự đoán. Cải thiện dựa trên những gì finance và ops thực sự thấy hàng ngày.

Câu hỏi thường gặp

Một cổng hạn mức tín dụng là kiểm tra tự động tạm dừng đơn hàng khi số nợ hiện tại của khách cộng với đơn hàng mới vượt quá hạn mức tín dụng đã thỏa thuận. Mục tiêu không phải là từ chối bán hàng vĩnh viễn, mà là dừng việc giao hàng và lập hóa đơn cho đến khi ai đó xem xét rủi ro và quyết định bước tiếp theo.

Hầu hết các đội định nghĩa phơi bày là tổng hóa đơn chưa thanh toán cộng với giá trị các đơn hàng mở chưa được lập hóa đơn hoặc chưa thanh toán. Điều quan trọng là ghi lại một định nghĩa duy nhất, để bộ phận kế toán đồng ý, và dùng cùng công thức ở mọi nơi để phê duyệt và báo cáo trùng khớp.

Ưu tiên bao gồm bất cứ thứ gì sẽ xuất hiện trên hóa đơn, vì như vậy tránh việc chấp thuận những đơn sau đó vượt quá hạn mức khi thuế hoặc phí vận chuyển được cộng thêm. Nếu thuế và vận chuyển dao động lớn, bạn có thể loại trừ chúng, nhưng cần bổ sung biên an toàn hoặc kiểm tra lại khi lập hóa đơn để tránh bất ngờ.

Chạy kiểm tra khi đơn được tạo, và chạy lại khi có bất kỳ thay đổi nào có thể làm tăng số tiền khách nợ, như thay đổi số lượng, thay đổi giá, gỡ giảm giá, hoặc thêm phí vận chuyển. Cũng nên kiểm tra lại khi có các sự kiện chuyển giá trị giữa các nhóm, ví dụ khi lập hóa đơn và khi ghi nhận thanh toán, để trạng thái luôn chính xác.

Một tạm giữ nên chặn các bước không thể đảo ngược, chủ yếu là lấy hàng, đóng gói, giao hàng và lập hóa đơn. Vẫn có thể ghi nhận đơn và liên lạc với khách, và một số đội có thể dự trữ hàng, nhưng mặc định an toàn là không dành kho cho đến khi tạm giữ được gỡ hoặc chỉ dùng cửa sổ dự trữ ngắn hạn.

Lưu các override tạm thời riêng biệt với hạn mức chính, yêu cầu người phê duyệt, thời hạn hết hạn và lý do bằng văn bản. Điều này giữ hạn mức chính sạch sẽ, giúp loại trừ tạm thời dễ gỡ bỏ, và tạo dấu vết kiểm toán khi ai đó hỏi tại sao đơn được cho phép.

Thông báo ngay cho những người có thể hành động, thường là bộ phận finance và một quản lý dự phòng. Thêm nhắc nhở và leo thang với thời hạn rõ ràng để tạm giữ không bị quên, và cân nhắc quy tắc hủy tự động nếu không ai xử lý trong khoảng thời gian định trước.

Tự động gỡ tạm giữ phù hợp khi các khoản thanh toán được đối chiếu chính xác với hóa đơn sẽ giảm công việc thủ công và đẩy nhanh việc thực hiện. Gỡ thủ công an toàn hơn khi thanh toán bị chia nhỏ, không rõ ràng hoặc thường xuyên tranh chấp, vì cần người xác nhận số tiền thực sự đã được thanh toán trước khi tiếp tục giao hàng.

Nếu lưu điều khoản bằng văn bản tự do, việc chỉnh sửa sau này có thể thay đổi bối cảnh quyết định và làm cho các quyết định cũ khó giải thích. Một cách đơn giản là chụp nhanh (snapshot) điều khoản và các chỉ số tín dụng lên đơn lúc tạo hoặc phê duyệt, để đơn giữ nguyên bối cảnh quyết định ngay cả khi hồ sơ khách thay đổi.

Có. Bạn có thể mô hình hóa khách hàng, đơn hàng, hóa đơn và override dưới dạng thực thể dữ liệu và thực hiện cổng như một quy trình backend tính toán lại phơi bày khi tạo, sửa, lập hóa đơn và khi có thanh toán. Cách này phù hợp khi bạn muốn trạng thái nhất quán, dấu vết kiểm toán và thông báo mà không cần viết toàn bộ workflow bằng tay.