---
title: "Thanh toán trong CRM công ty du học: khoảng cách giữa \"được nợ\" và \"đã nhận\", và năm câu hỏi chốt sổ hàng tháng"
description: "EducationLink, Agentcis và Edvisor thực sự ghi nhận gì về thanh toán, vì sao ngân hàng mới là sổ cái thật, và năm câu hỏi đối soát cần hỏi mỗi tháng."
date: "2026-03-12"
category: "Hiệu quả vận hành"
keywords: "Hiệu quả vận hành"
author: "Raphael Arias"
lang: "vi"
wordCount: 5746
url: https://qualyhq.com/vi/blog/doi-soat-thanh-toan-crm-du-hoc
---
## Site navigation

- [Cho trường học](/vi/giao-duc-quoc-te/cho-truong-hoc.md) — Dành cho các trường có sinh viên quốc tế
- [Cho đại lý](/vi/giao-duc-quoc-te/cho-dai-ly.md) — Dành cho các đại lý giáo dục
- [Bảng giá](/vi/bang-gia)
- [Demo 5 phút](/vi/demo.md) — Video demo 5 phút
- [Đăng nhập](https://dashboard.qualyhq.com)

# Thanh toán trong CRM công ty du học: khoảng cách giữa "được nợ" và "đã nhận", và năm câu hỏi chốt sổ hàng tháng

> EducationLink, Agentcis và Edvisor thực sự ghi nhận gì về thanh toán, vì sao ngân hàng mới là sổ cái thật, và năm câu hỏi đối soát cần hỏi mỗi tháng.

CRM của công ty du học ghi nhận các khoản thanh toán; nó không xác nhận chúng. EducationLink, Agentcis và Edvisor theo dõi số tiền bạn được nợ — hóa đơn, trạng thái, phần chia hoa hồng — nhưng sổ cái làm chuẩn lại là tài khoản ngân hàng của bạn, và giữa hai thứ đó là khoảng cách giữa "được nợ" và "đã nhận": hoa hồng không bao giờ được xuất hóa đơn, hóa đơn bị trả thiếu, phần chia được trả trên khoản tiền chưa được xác nhận, khoản thu hồi không bao giờ được ghi ngược lại. Năm câu hỏi, hỏi mỗi tháng, sẽ khép lại khoảng cách đó.

Đó là thứ Sáu đầu tiên của tháng. Báo cáo hoa hồng trong CRM nói tháng vừa rồi rất tốt: 41 ca ghi danh đã xác nhận, 63.000 AUD hoa hồng đã xuất hóa đơn, mọi phần chia cho đại lý phụ được tính chính xác đến từng đồng. Rồi bạn mở sao kê ngân hàng, và nó kể một câu chuyện khác — ba khoản tiền vào không khớp với hóa đơn nào, một hóa đơn chẳng có khoản tiền vào nào cả, và một khoản trường chuyển về nhẹ hơn con số CRM đang ăn mừng tới 900 AUD. Hai chứng từ, hai phiên bản về tháng của bạn. Đây là phần khó chịu: **ngân hàng đúng. Nó luôn đúng.**

Đây không phải bài viết về việc CRM của bạn bị hỏng. Nó không hỏng — nó *đầy đủ*. Nó trả lời đúng những câu hỏi mà nó được xây để trả lời: học viên nào, trường nào, tình trạng pipeline ra sao, bạn được nợ bao nhiêu hoa hồng. Rồi nó dừng lại, đúng ngay điểm tiền bắt đầu chuyển động, vì công việc bên kia ranh giới đó là một công việc khác. Tôi đã trình bày phiên bản tổng quát của lập luận này trước đây — [một hệ thống quản lý theo dõi tiền của bạn; nó không chuyển tiền](/blog/education-agency-management-system-payments-gap.md). Bài này là phần tiếp nối ở góc độ vận hành: cái gì thực sự rơi vào khoảng trống giữa CRM và ngân hàng, và năm câu hỏi kéo nó trở lại, mỗi tháng một buổi sáng.

## "Thanh toán" nghĩa là gì bên trong EducationLink, Agentcis và Edvisor

Hãy bắt đầu bằng sự công bằng với phần mềm, vì phần mềm thực sự giỏi việc của nó. [EducationLink](https://geteducation.link/education-agents/) — do chính tôi sáng lập, nên tôi hiểu tham vọng của nó từ bên trong — mô tả một mô-đun kế toán được xây riêng cho các công ty du học: quản lý thỏa thuận, tính hoa hồng, tự động xuất hóa đơn hoa hồng, biên nhận thanh toán của học viên, hoàn tiền, kế toán đại lý phụ. [Agentcis](https://agentcis.com/features/invoicing/) cung cấp hóa đơn hoa hồng theo net-claim và gross-claim kèm nhắc nhở — "để bạn không bao giờ mất hoa hồng," theo lời chính họ — và nói rằng hơn 4.000 đại lý tin dùng. [Edvisor](https://edvisor.io/) đặt dòng chữ "Get Paid" ngay trên trang chủ: theo dõi hoa hồng và kế hoạch thanh toán, tất cả một chỗ. Không có gì trong số này là khoa trương. Những tính năng này tồn tại, chúng hoạt động, và một công ty dùng chúng thì gọn gàng hơn một công ty không dùng.

Giờ đọc lại những danh sách tính năng đó và để ý các động từ: *tính toán, tạo, theo dõi, nhắc nhở, ghi nhận*. Mỗi động từ đều là một động từ ghi chép. Động từ không bao giờ xuất hiện là **xác nhận** — vì xác nhận không phải thứ phần mềm có thể tự gõ vào chính nó. **Một trạng thái thanh toán trong CRM là một lời khẳng định, thường bởi một con người đang bận, rằng tiền đã chuyển; còn một khoản ghi có ở ngân hàng chính là tiền.** Khi đồng nghiệp của bạn đánh dấu một hóa đơn là "Đã thanh toán" vì email báo chuyển tiền của trường đã tới, CRM giờ nắm giữ một niềm tin. Niềm tin đó có đúng hay không — đủ số tiền, đúng loại tiền tệ, thực sự đã về tài khoản — là một sự thật nằm ở nơi CRM không nhìn thấy được: tài khoản ngân hàng của bạn.

Đây là bản đồ trung thực về những gì các trường trạng thái thông thường thực sự chứng thực, và cần gì để kiểm chứng từng thứ.

| Trạng thái CRM | Nó thực sự ghi nhận gì | Điều chỉ ngân hàng mới cho bạn biết |
| --- | --- | --- |
| Ghi danh có hoa hồng | Phép tính của CRM nói rằng có một khoản đòi | Chưa gì cả — nhưng không ai được trả tiền trên dòng này |
| Đã gửi hóa đơn | Một chứng từ đã được tạo và gửi email | Liệu tiền có bao giờ đi theo nó |
| Đã thanh toán | Một người đã bấm nút, thường từ một email báo chuyển tiền | Liệu khoản tiền có về đủ, và đủ toàn bộ số tiền |
| Đã tính phần chia | Phép tính trên khoản hoa hồng mà CRM tin là có | Liệu tiền gốc đã về trước khi bạn chia đi hay chưa |
| Đã xử lý hoàn tiền / thu hồi | Một trạng thái đã thay đổi trên hồ sơ học viên | Liệu tiền có thực sự rời đi, và bao nhiêu |

*Suy ra từ mô tả tính năng công khai của các nhà cung cấp, kiểm chứng tháng 7/2026. Đây là bản đồ theo nhóm, không phải bản kiểm toán một sản phẩm cụ thể — hãy đối chiếu với quy trình của chính bạn.*

## Sổ cái làm chuẩn là tài khoản ngân hàng của bạn

Kế toán đã giải quyết bài toán này từ nhiều thế kỷ trước khi có ai bán CRM. Người làm sổ sách giữ những sổ phụ chi tiết — một **sổ chi tiết công nợ** — cho bất cứ thứ gì đáng ghi từng khoản: số dư của từng khách hàng, hóa đơn của từng nhà cung cấp. Và họ giữ một quy tắc sắt: *một sổ chi tiết phải được đối soát với ngân hàng, theo lịch, nếu không thì không đáng tin.* Mọi kế toán mà công ty bạn từng thuê đều làm việc này cho sổ kế toán mà chẳng cần ai nhắc. **CRM của bạn là một sổ chi tiết hoa hồng mà không ai đối soát**, vì nó không được bán như một cuốn sổ kế toán — nó được bán như một công cụ bán hàng có gắn thêm một tab kế toán, và không ai giao cho cái tab đó một kiểm toán viên.

Khoảng cách mà điều này tạo ra xứng đáng có một cái tên, nên hãy đặt cho nó một cái: **khoảng cách giữa "được nợ" và "đã nhận"** — khoảng cách giữa số tiền CRM nói bạn đã kiếm được và số tiền ngân hàng xác nhận bạn đã thực nhận. Khoảng cách này không phải trôi dạt trên lý thuyết; nó được tạo ra liên tục, bởi những quy luật vật lý bình thường của ngành này. Trường trả hoa hồng trễ — trong một ghi nhận từ báo chí ngành, một công ty cho biết [chỉ 60% các trường đối tác trả đúng hạn](https://thepienews.com/only-60-of-our-institutions-pay-on-time/). Tiền vượt biên giới về thiếu, bị cắt bởi chênh lệch tỷ giá và phí trung gian mà hóa đơn chẳng bao giờ nhắc đến. Trường chuyển net trong khi bạn xuất gross, hoặc ngược lại — [cuộc tranh cãi sổ sách xưa nhất của ngành](/blog/how-education-agent-commissions-work.md). Mỗi sự kiện này đều làm thay đổi con số thật trong ngân hàng trong khi con số của CRM đứng yên. Một CRM chính xác 98% nghe rất tuyệt cho tới khi bạn nhớ ra rằng 2% kia không phải thiện chí được phân bổ đều — nó là những đồng cụ thể, và chúng là của bạn.

## Nơi tổn thất trú ngụ: bốn lần bàn giao xuôi, một lần chạy ngược

Tiền không biến mất khỏi một công ty ở một chỗ kịch tính duy nhất. Nó rò rỉ tại các điểm bàn giao — nơi mà bản ghi của CRM phải trở thành, hoặc phải phản hồi, một sự kiện ngân hàng. Có bốn điểm chạy xuôi và một điểm chạy ngược.

**1. Được nợ nhưng không bao giờ xuất hóa đơn.** CRM tính ra rằng một ca ghi danh có hoa hồng; một con người vẫn phải lập khoản đòi. Trường gần như không bao giờ đuổi theo để đòi bạn gửi hóa đơn cho họ. Hãy tự làm phép tính trên khối lượng của chính bạn: **một công ty chốt 300 ca ghi danh mỗi năm mà không xuất hóa đơn chỉ 2% trong số đó thì mất hoa hồng của sáu ca — thường là con số năm chữ số — mà không có bản ghi nào cho thấy nó từng bị bỏ sót.** (Đây là minh họa dựa trên giả định đã nêu, không phải số liệu thống kê — và đó chính là vấn đề: hoa hồng chưa xuất hóa đơn không sinh ra bằng chứng nào.) Nếu vấn đề sâu xa hơn là bạn không chắc mức nào áp dụng theo thỏa thuận nào, thì đó là vấn đề hợp đồng trước khi là vấn đề hóa đơn — [Feezy được xây cho đúng cái tủ hồ sơ đó](/blog/feezy-digital-contract-management-education-agents.md).

**2. Đã xuất hóa đơn nhưng bị trả thiếu.** Một khoản tiền về và nó ít hơn hóa đơn: một lần quy đổi tiền tệ đã xảy ra trên đường đi, một ngân hàng trung gian đã lấy phí, hoặc trường đã trừ đi thứ gì đó mà họ cho là hiển nhiên còn bạn thì mới nghe lần đầu. Cú bấm lạc quan đánh dấu hóa đơn là "Đã thanh toán" ở giá trị đầy đủ, và phần thiếu — thường 2–4% — âm thầm được tha, mỗi tháng, mãi mãi.

**3. Đánh dấu đã thanh toán trên khoản tiền chưa bao giờ về tài khoản.** Học viên tải lên một biên nhận chuyển tiền; tư vấn viên cập nhật trạng thái; giao dịch chuyển tiền bị trả về, hoặc một khoản thanh toán thẻ bị đảo ngược nhiều tuần sau. Trường trạng thái đã chạy nhanh hơn tiền mặt, và giờ mọi con số phía dưới — số dư của trường, kỳ vọng hoa hồng của bạn — đều thừa hưởng lỗi ấy.

**4. Chia phần trên những con số chỉ được tin là đúng.** Cái tốn kém nhất. CRM của bạn tính phần của đại lý phụ ngay khoảnh khắc hoa hồng được ghi nhận, và việc trả phần chia dựa trên phép tính đó là điều tự nhiên. Nhưng nếu khoản của trường chưa về — hoặc về thiếu — thì bạn đã trả tiền thật ra ngoài để đối lấy tiền tưởng tượng vào. [Trả hoa hồng cho đại lý phụ cho tốt là một kỷ luật bốn quyết định](/blog/sub-agent-commission-payments.md), và quyết định đầu tiên là cái nút bấm khởi động: **phần chia nên được trả trên khoản ghi có đã xác nhận ở ngân hàng, không bao giờ trên số dư trong CRM.**

**5. Thu hồi không bao giờ được ghi ngược lại.** Cái này chạy ngược: ngân hàng chuyển động, CRM thì không. Một học viên rút lui, trường thu hồi hoa hồng — bằng hóa đơn hoặc bằng cách lặng lẽ khấu trừ vào sao kê kỳ tới của bạn — và trừ khi có ai đó đối soát sự kiện đó *trở lại vào* CRM, hệ thống làm chuẩn của bạn giờ khai khống số tiền bạn đã kiếm, đại lý phụ của bạn giữ một phần chia mà bạn đã trả lại, và báo cáo tháng sau được xây trên một điều hư cấu. [Thu hồi hoa hồng là một bãi mìn hợp đồng riêng](/blog/education-agent-commission-clawbacks.md); điểm vận hành ở đây hẹp hơn: một khoản thu hồi không được ghi ngược vào CRM là một tổn thất mà bạn chắc chắn sẽ đếm trùng theo hướng có lợi cho mình, rồi phát hiện ra vào thời điểm tệ nhất.

## Buổi chốt sổ hàng tháng gồm năm câu hỏi

Kế toán gọi nghi thức hoàn tất số liệu của một kỳ là **chốt sổ**. Công ty du học cũng cần một buổi như vậy — nhỏ hơn, sắc hơn, nhắm vào năm điểm bàn giao ở trên. Chặn ra một buổi sáng mỗi tháng, đặt báo cáo hoa hồng của CRM cạnh sao kê ngân hàng, và hỏi, theo thứ tự:

1. **Mọi ca ghi danh có hoa hồng đã có hóa đơn được lập chưa?** Lọc CRM để tìm các ca ghi danh đã qua ngày chốt (census hoặc tương đương) mà chưa có hóa đơn đính kèm. Mỗi dòng là tiền chưa có khoản đòi nào bám vào — tổn thất rẻ nhất để phòng ngừa, vì phòng ngừa chỉ là một email.
2. **Mọi hóa đơn đánh dấu "Đã thanh toán" có một khoản ghi có ngân hàng khớp — đủ toàn bộ số tiền không?** Khớp hóa đơn với khoản tiền vào, số tiền với số tiền. Thiếu một khoản ghi có nghĩa là trạng thái đã nói dối. Một khoản ghi có thiếu là một cuộc trao đổi với trường, hoặc một khoản chi phí mà ít nhất bạn nên *chọn* gánh thay vì gánh vì không để ý.
3. **Mọi khoản học viên thanh toán mà CRM ghi là đã nhận có ứng với tiền đã về tài khoản không?** Biên nhận và email báo chuyển tiền là lời khai; chỉ khoản ghi có đã về mới là bằng chứng. Bất cứ khoản nào treo lâu hơn một khung thời gian chuyển tiền bình thường thì phải đuổi theo ngay tháng này, chứ không phải phát hiện lúc nhập học.
4. **Mọi khoản trả cho đại lý phụ đã được khớp với một khoản trường trả đã xác nhận trước khi nó rời đi chưa?** Nếu bạn thấy các phần chia được trả trước khi hoa hồng về tài khoản, hãy siết chặt cái nút khởi động. Bạn không hề chậm — bạn đang từ chối cho rủi ro thời gian vay lãi biên của mình miễn phí.
5. **Mọi khoản hoàn tiền, rút lui và thu hồi đã được ghi ngược lại vào CRM chưa?** Hoa hồng đã đảo, phần chia được đánh dấu để thu hồi, hồ sơ học viên được cập nhật. Đây là câu hỏi không phần mềm nào nhắc bạn, vì nó bắt đầu từ ngân hàng và ngân hàng không nói chuyện với CRM.

Buổi chốt sổ đầu tiên là buổi chậm — hãy dự trù gần trọn một ngày, và hãy dự trù nó tự bù lại chi phí: mọi công ty tôi từng thấy làm bài tập này lần đầu đều tìm thấy ít nhất một khoản đòi chưa xuất hóa đơn hoặc một khoản thiếu chưa được đối soát. (Đó là kinh nghiệm của tôi qua các công ty tôi đã làm việc cùng, không phải một nghiên cứu — hãy coi nó là một quy luật do một nhà sáng lập nhận ra, và kiểm chứng nó trên sổ sách của chính bạn.) Sau tháng đầu tiên thì chỉ còn hai đến ba tiếng, và con số nó bảo vệ là toàn bộ biên lợi nhuận của bạn, vì **mỗi một trong năm câu hỏi đều là một chỗ mà sự tự tin của CRM và sự thật của ngân hàng có thể lặng lẽ bất đồng.**

## Đối soát bằng VND trên hạ tầng nội địa: khi tiền không cần vượt biên giới

Đến đây một sự thật rất Việt Nam làm cho khoảng cách giữa "được nợ" và "đã nhận" vừa dễ hơn vừa khó hơn cùng lúc. Dễ hơn khi tiền ở trong nước: một gia đình trả khoản đặt cọc hay phí dịch vụ qua chuyển khoản liên ngân hàng tức thời Napas 247 quét mã VietQR, hoặc qua ví điện tử như MoMo, ZaloPay, VNPay, thì khoản ghi có về tài khoản gần như ngay lập tức, kèm nội dung chuyển khoản mà chính người trả gõ vào. Đó là loại bằng chứng mà buổi chốt sổ mong muốn: tiền thật, bằng VND, khớp với một hồ sơ cụ thể, không phải một email báo chuyển tiền chờ được xác nhận.

Cái khó bắt đầu ngay khi bạn dựa vào nội dung chuyển khoản đó để đối soát bằng tay. Một cú quét VietQR về đúng số tiền vẫn là một dòng trên sao kê mà ai đó phải khớp lại với đúng học viên — và khi một phụ huynh trả cọc còn học viên trả phần còn lại từ một tài khoản khác, hoặc khi nội dung ghi vỏn vẹn "chuyen tien hoc", thì công việc khớp tay quay lại y như cũ. Hạ tầng nội địa xóa được độ trễ và loại bỏ chi phí quy đổi; nó không tự xóa được lao động đối soát. Đó vẫn là hai hệ thống chưa từng được giới thiệu với nhau: CRM tin vào một trạng thái, ngân hàng nắm giữ sự thật.

### Chi phí thật khi tiền vượt biên giới

Khoảng cách phình to nhất đúng lúc tiền qua biên giới. Khi trường ở nước ngoài trả hoa hồng về bằng ngoại tệ qua điện SWIFT, khoản về tài khoản gần như luôn nhẹ hơn con số trên hóa đơn — bị cắt bởi chênh lệch tỷ giá mua vào của ngân hàng, phí điện, và phí của một hay nhiều ngân hàng trung gian mà không ai báo trước. Đó chính xác là kịch bản "đã xuất hóa đơn nhưng bị trả thiếu" ở trên, chỉ có điều phần thiếu ở đây lớn hơn và khó truy nguyên hơn, vì nó bị chôn trong một tỷ giá thay vì một dòng khấu trừ rõ ràng. Cú bấm lạc quan đánh dấu "Đã thanh toán" ở giá trị đầy đủ, và biên lợi nhuận của bạn lặng lẽ chảy vào chênh lệch tỷ giá.

Chiều ngược lại cũng vậy: khi bạn phải trả học phí hay chuyển tiền ra nước ngoài cho một đối tác, mỗi lần chuyển gánh thêm phí SWIFT cộng chênh lệch tỷ giá bán ra, và mỗi lần lại là một khoản mà buổi chốt sổ phải bóc tách bằng tay để biết trường thực nhận bao nhiêu. Nhân những khoản này với vài chục giao dịch một tháng, và chi phí lao động của việc đối soát tay cũng thật ngang với chính khoản chênh lệch tỷ giá.

Đây là chỗ việc thu và chi trên hạ tầng nội địa gỡ được nút thắt mà không đẩy chi phí sang phía đối tác. Một gia đình trả bằng VND qua Napas 247 / VietQR hoặc ví điện tử, trong khi trường vẫn nhận bằng đúng loại tiền của mình; đại lý phụ trong nước được trả bằng VND từ khoản đã về tài khoản. Khi nền tảng thu tiền của học viên cũng chính là nền tảng trả tiền cho trường và trả phần chia cho đại lý phụ, thì các câu hỏi hai đến năm gần như tự trả lời: bản ghi và chuyển động là cùng một sự kiện, bằng VND, khớp ngay khi tiền chuyển động. Bạn giữ hạ tầng nội địa mà gia đình đã quen, đối tác giữ loại tiền của họ, và bạn không còn phải trả cả chi phí tỷ giá lẫn chi phí lao động của việc ghép nối hai hệ thống bằng tay.

## Chẳng phải CRM rồi sẽ tự thêm thanh toán sao? Một phần — và Edvisor đã làm

Phản biện hiển nhiên: chắc chắn rồi các CRM sẽ tự khép khoảng cách này. Bằng chứng cho thấy họ đang cố, và một trong số họ đã ra mắt. Edvisor cung cấp [EdWallet](https://help.edvisor.io/edwallet/what-is-edwallet), một tính năng thanh toán xây trên quan hệ đối tác với TransferMate (một nhà cung cấp thanh toán), cho phép các công ty và trường nhận, gửi và rút tiền bằng nhiều loại tiền tệ ngay trong hệ sinh thái Edvisor, không mất thêm phí nền tảng. Trang của Edvisor cũng nêu 2 tỷ đô-la học phí đã xử lý qua nền tảng — một con số cho bạn biết các nhà cung cấp hiểu rõ sản phẩm tiếp theo nằm ở đâu. Tài liệu công khai của EducationLink mô tả các kết nối tới Xero, Mailchimp và Gmail, không phải việc chuyển tiền. Tài liệu công khai của Agentcis mô tả xuất hóa đơn, nhắc nhở và một tích hợp dữ liệu Studylink Connect, không phải việc chuyển tiền.

Vậy đây là một tuyên bố có thể bác bỏ để bạn bắt lỗi tôi: **đến hết năm 2028, hãy chờ đợi các CRM lớn của ngành cung cấp một tính năng thanh toán tích hợp qua quan hệ đối tác với một nhà cung cấp thanh toán, như Edvisor đã làm — và hãy chờ đợi khoảng cách giữa "được nợ" và "đã nhận" sống sót qua bản nâng cấp đó.** Lý do mang tính cấu trúc, không phải hoài nghi. Một tính năng thanh toán tích hợp chỉ xác nhận đúng phần tiền chảy qua nó. Học viên trả thẳng cho trường, trường đại học trả hoa hồng bằng chuyển khoản ngân hàng vì đó là cách bộ phận tài chính của họ làm, khoản thu hồi được khấu trừ vào sao kê quý sau — tất cả đều xảy ra ngoài mọi luồng tích hợp, và về, như thường lệ, tài khoản ngân hàng của bạn. Sự hội tụ sẽ thu hẹp khoảng cách cho một lát tiền của bạn. Buổi chốt sổ bao trùm toàn bộ. Nếu bạn đang cân nhắc liệu hệ thống hiện tại của mình có phải là hệ thống đúng hay không, [hướng dẫn thang trưởng thành](/blog/do-you-need-education-agency-management-system.md) và [luận điểm trung thực cho việc chờ đợi](/blog/should-small-education-agencies-invest-in-crm-payment-systems.md) là những câu trả lời dài hơn; dù bạn ở nấc nào, buổi chốt sổ vẫn áp dụng.

## Chốt sổ là việc dành cho một hệ thống đã tận mắt thấy tiền

Mọi thứ ở trên đều làm được bằng tay, và nếu bạn rút ra một điều từ bài này, hãy rút ra năm câu hỏi và một khối lịch định kỳ. Nhưng hãy để ý điều gì khiến buổi chốt sổ vất vả: bạn đang ghép lại bằng tay hai hệ thống chưa từng được giới thiệu với nhau. Giải pháp thay thế không phải một CRM tốt hơn — mà là đặt phần tiền lên một hệ thống *ghi nhận các khoản thanh toán vì chính nó đã thực hiện chúng*. Khi nền tảng thu tiền của học viên cũng là nền tảng trả tiền cho trường và trả phần chia cho đại lý phụ, các câu hỏi hai đến năm tự trả lời: [kế toán tự đối soát](/features/automatic-accounting-for-ed-agents.md) vì bản ghi và chuyển động là cùng một sự kiện, và [phần chia được trả từ tiền đã xác nhận](/features/master-and-sub-agent-payments.md), không phải từ những con số chỉ được tin là đúng. Đó là phía ranh giới mà Qualy được xây cho — nó kết nối với CRM bạn đang dùng thay vì thay thế nó (có [một so sánh trực tiếp với EducationLink](/compare/educationlink.md) nếu đó là hệ thống của bạn), và nó tính một khoản phí cố định trên mỗi giao dịch thay vì một tỷ lệ phần trăm ẩn trong tỷ giá.

Giữ CRM lại. Nó giỏi việc của nó, và việc của nó kết thúc đúng chỗ tiền của bạn bắt đầu chuyển động. Chỉ cần ngừng cho rằng hai nửa ấy khớp nhau. Mỗi tháng một lần, bắt chúng chứng minh điều đó.

## Nguồn

- [EducationLink — dành cho đại lý giáo dục](https://geteducation.link/education-agents/): mô tả của chính nhà cung cấp về mô-đun kế toán — quản lý thỏa thuận, tính hoa hồng, tự động xuất hóa đơn hoa hồng, biên nhận thanh toán của học viên, hoàn tiền, kế toán đại lý phụ — cùng các kết nối Xero, Mailchimp và Gmail.
- [Agentcis](https://agentcis.com/): tuyên bố của nhà cung cấp về hơn 4.000 đại lý và tích hợp dữ liệu Studylink Connect.
- [Agentcis — tính năng xuất hóa đơn](https://agentcis.com/features/invoicing/): hóa đơn hoa hồng net-claim và gross-claim, thông báo nhắc nhở, ghi nhận chiết khấu.
- [Edvisor](https://edvisor.io/): định vị "Get Paid — theo dõi hoa hồng và kế hoạch thanh toán" và con số 2 tỷ đô-la học phí đã xử lý như công bố trên trang của nhà cung cấp.
- [Edvisor Help Center — EdWallet là gì?](https://help.edvisor.io/edwallet/what-is-edwallet): các khả năng của EdWallet (nhận, gửi, quản lý, rút; đa tiền tệ), quan hệ đối tác TransferMate, và việc cung cấp miễn phí thêm cho người dùng Edvisor.
- [The PIE News — "Chỉ 60% các trường của chúng tôi trả đúng hạn"](https://thepienews.com/only-60-of-our-institutions-pay-on-time/): các ghi nhận của đại lý về việc trường đối tác trả hoa hồng trễ.

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

### CRM của công ty du học có xử lý thanh toán không?

Nó ghi nhận thanh toán; nó không xác nhận hay chuyển tiền. EducationLink, Agentcis và Edvisor tính hoa hồng, tạo hóa đơn và theo dõi trạng thái thanh toán — việc ghi chép thật sự hữu ích. Nhưng một trường trạng thái là một lời khẳng định rằng tiền đã chuyển, còn bản thân tiền lại về tài khoản ngân hàng của bạn, nơi CRM không nhìn thấy. Ngoại lệ là các tính năng tích hợp như EdWallet của Edvisor, chỉ xác nhận đúng những khoản chảy qua chúng. Mọi thứ còn lại cần đối soát hàng tháng với ngân hàng.

### Khoảng cách giữa "được nợ" và "đã nhận" là gì?

Đó là khoảng cách giữa số tiền CRM nói bạn đã kiếm được và số tiền ngân hàng xác nhận bạn đã thực nhận. Nó được tạo ra bởi những sự kiện bình thường mà CRM không thể chứng kiến: hoa hồng không bao giờ được xuất hóa đơn, hóa đơn bị trả thiếu sau khi quy đổi tiền tệ và trừ phí, khoản học viên trả bị đánh dấu đã nhận trước khi về tài khoản, phần chia cho đại lý phụ trả trên những con số chưa xác nhận, và các khoản thu hồi không bao giờ được ghi ngược lại vào bản ghi.

### Theo dõi hoa hồng trong CRM thực sự ghi nhận gì?

Phép tính và lời khẳng định. CRM áp mức của thỏa thuận vào một ca ghi danh (một phép tính), tạo một hóa đơn (một chứng từ), và giữ một trạng thái như "Đã thanh toán" (lời khẳng định của một con người rằng tiền đã về). Không cái nào trong số này là xác nhận. Liệu khoản ghi có đã về, đúng loại tiền, đủ toàn bộ số tiền hay chưa, là một sự thật chỉ tồn tại trong tài khoản ngân hàng của bạn — đó là lý do hai bên cần được đối soát theo lịch.

### Làm sao để đối soát CRM công ty du học với tài khoản ngân hàng?

Mỗi tháng một lần, đặt báo cáo hoa hồng của CRM cạnh sao kê ngân hàng và hỏi năm câu: mọi ca ghi danh có hoa hồng đã có hóa đơn được lập chưa; mọi hóa đơn đánh dấu đã thanh toán có khoản ghi có ngân hàng khớp đủ toàn bộ số tiền không; mọi khoản học viên trả ghi là đã nhận có ứng với tiền đã về tài khoản không; mọi khoản trả cho đại lý phụ có được khớp với một khoản trường trả đã xác nhận không; và mọi khoản hoàn tiền hay thu hồi đã được ghi ngược lại vào CRM chưa. Dự trù một ngày cho lần đầu, sau đó hai đến ba tiếng.

### Vì sao CRM báo một học viên đã trả mà tiền chưa bao giờ về?

Vì có ai đó cập nhật trạng thái dựa trên lời khai chứ không phải bằng chứng — một biên nhận chuyển tiền học viên tải lên, hoặc một email báo chuyển tiền. Giao dịch chuyển tiền có thể bị trả về và thanh toán thẻ có thể bị đảo ngược sau cú bấm. Trường trạng thái khi đó chạy nhanh hơn tiền mặt, và mọi con số phía dưới thừa hưởng lỗi: số dư của trường trông như đã thanh toán và kỳ vọng hoa hồng của bạn trông như an toàn. Cách khắc phục mang tính quy trình: chỉ khoản ghi có đã về tài khoản, không phải biên nhận, mới biện minh cho trạng thái đã thanh toán.

### Tôi có nên trả phần chia cho đại lý phụ dựa trên con số của CRM không?

Không — hãy trả phần chia trên khoản ghi có đã xác nhận ở ngân hàng, không bao giờ trên số dư trong CRM. CRM tính phần của đại lý phụ ngay khoảnh khắc hoa hồng được ghi nhận, nhưng nếu khoản của trường chưa về, hoặc về thiếu, thì trả phần chia nghĩa là gửi tiền thật ra để đối lấy tiền tưởng tượng vào. Nếu khoản của trường sau đó bị giảm hoặc bị thu hồi, bạn phải đuổi theo chính đại lý phụ của mình để lấy lại phần chênh — cuộc thu hồi khó xử nhất trong nghề.

### Điều gì xảy ra khi một khoản thu hồi hoa hồng không được ghi vào CRM?

Hệ thống làm chuẩn của bạn bắt đầu khai khống thực tế. Ngân hàng đã chuyển động — trường xuất hóa đơn đòi lại hoặc khấu trừ vào sao kê kỳ tới của bạn — nhưng CRM vẫn báo hoa hồng là đã kiếm được, đại lý phụ giữ một phần chia mà bạn đã thực trả lại, và mọi báo cáo xây trên CRM thừa hưởng điều hư cấu đó. Việc đối soát ở đây chạy ngược: nó bắt đầu từ ngân hàng và phải được ghi vào CRM bằng tay, đó là lý do đây là bước ai cũng bỏ qua.

### Ở Việt Nam, hạ tầng nội địa như Napas 247 có xóa được việc đối soát không?

Nó xóa được phần khó nhất — độ trễ và chi phí quy đổi — chứ không xóa hết. Khi một gia đình trả bằng VND qua chuyển khoản Napas 247 quét mã VietQR hoặc qua ví điện tử như MoMo, ZaloPay, VNPay, khoản ghi có về gần như tức thời và bằng bằng chứng thật, không phải một email chờ xác nhận. Nhưng bạn vẫn phải khớp mỗi dòng sao kê với đúng học viên, nhất là khi phụ huynh trả cọc còn học viên trả phần còn lại, hoặc khi nội dung chuyển khoản mơ hồ. Hạ tầng nội địa loại bỏ chi phí; nó không tự loại bỏ lao động đối soát trừ khi thu và ghi nhận là cùng một sự kiện.

### Chi phí thật khi hoa hồng vượt biên giới về Việt Nam là gì?

Khi trường ở nước ngoài trả hoa hồng bằng ngoại tệ qua điện SWIFT, khoản về tài khoản gần như luôn nhẹ hơn hóa đơn — bị cắt bởi chênh lệch tỷ giá mua vào, phí điện, và phí của một hay nhiều ngân hàng trung gian không được báo trước. Đây chính là kịch bản "đã xuất hóa đơn nhưng bị trả thiếu", chỉ khác là phần thiếu bị chôn trong một tỷ giá thay vì một dòng khấu trừ rõ ràng, nên khó truy nguyên hơn. Cách gỡ là thu bằng VND trên hạ tầng nội địa trong khi trường vẫn nhận bằng loại tiền của họ, để bạn không trả cả chi phí tỷ giá lẫn chi phí lao động đối soát.

### Làm sao để khớp một khoản chuyển khoản VietQR hay ví điện tử với đúng học viên?

Vấn đề không phải tiền chậm — với Napas 247 và ví như MoMo, ZaloPay, VNPay, tiền về gần như tức thời — mà là nội dung chuyển khoản. Một dòng ghi "chuyen tien hoc" hoặc một khoản ví không tên vẫn cần ai đó ghép lại với một hồ sơ cụ thể, và việc này còn rối hơn khi phụ huynh trả cọc từ một tài khoản còn học viên trả phần còn lại từ tài khoản khác. Cách gọn nhất là mỗi khoản thu gắn sẵn một mã tham chiếu duy nhất cho từng học viên, để khoản ghi có tự khớp khi về — nghĩa là thu và ghi nhận trở thành cùng một sự kiện, thay vì hai dòng phải ghép tay mỗi tháng.

### CRM ngành du học có tích hợp thanh toán vào năm 2028 không?

Dự đoán có thể bác bỏ của tôi: đến hết năm 2028 các CRM lớn của ngành sẽ cung cấp tính năng thanh toán tích hợp qua quan hệ đối tác với nhà cung cấp thanh toán, theo mô hình EdWallet của Edvisor, thay vì tự xây hạ tầng thanh toán. Điều không thay đổi là nghĩa vụ đối soát — một tính năng tích hợp chỉ xác nhận đúng lát tiền của nó, nên buổi chốt sổ hàng tháng với sao kê vẫn là việc của bạn cho mọi thứ chuyển động bên ngoài nó.

### Tôi có cần thay CRM để sửa việc đối soát không?

Không. CRM đang làm đúng việc của nó — hồ sơ, pipeline, phép tính hoa hồng — và đổi nó lấy một đối thủ sẽ không làm sao kê ngân hàng khớp. Bạn có hai lựa chọn thật: chạy buổi chốt sổ năm câu hỏi bằng tay, tốn vài tiếng và bảo vệ toàn bộ biên lợi nhuận, hoặc đặt phần tiền lên một hệ thống thanh toán ghi nhận các khoản vì chính nó đã thực hiện chúng, để việc thu, trả cho trường và chia cho đại lý phụ tự đối soát. Dù chọn cách nào, hãy giữ CRM lại.

## Related articles

- [Does your education agency management system actually move money? The records-vs-payments gap](/blog/education-agency-management-system-payments-gap.md)
- [Sub-agent commission payments: when to pay, in what currency, and with what paperwork](/blog/sub-agent-commission-payments.md)
- [Education agent commission clawbacks: the five triggers, the missing window, and how to design the clause](/blog/education-agent-commission-clawbacks.md)

## More on Qualy

**Lĩnh vực**

- [Cho trường học](/vi/giao-duc-quoc-te/cho-truong-hoc.md) — Dành cho các trường có sinh viên quốc tế
- [Cho đại lý](/vi/giao-duc-quoc-te/cho-dai-ly.md) — Dành cho các đại lý giáo dục

**Hỗ trợ**

- [Trạng thái hệ thống](https://qualyhq.statuspage.io/) — Trạng thái hệ thống Qualy
- [Liên hệ](/vi/lien-he.md)

**Sản phẩm**

- [Demo](/vi/demo.md)
- [Ý kiến khách hàng](/vi/y-kien-khach-hang.md) — Xem khách hàng nói gì về Qualy
- [Trung tâm minh bạch](/vi/trung-tam-minh-bach.md)
- [API](/vi/api.md) — API Qualy cho thanh toán du học và đại lý giáo dục
- [Blog](/vi/blog) — Blog Qualy về thanh toán trong giáo dục quốc tế

**Pháp lý (bằng tiếng Anh)**

- [Điều khoản chung](/terms-and-conditions.md) — Điều khoản và Điều kiện
- [Điều khoản người thanh toán](/terms-for-payers.md) — Điều khoản cho người thanh toán