Bài 3 — Hạch toán kép & Sổ cái (GL): Ngôn ngữ của ngân hàng

Nếu phải chọn MỘT bài quan trọng nhất trong cả loạt, thì đây là bài đó. Hạch toán kép (double-entry bookkeeping) không phải là "một quy ước kế toán khô khan" — nó là ngôn ngữ chung mà toàn bộ ngân hàng dùng để mô tả mọi sự kiện tiền tệ. Khi bạn hiểu thấu đáo Nợ/Có và Sổ cái, bạn sẽ "đọc" được bất kỳ giao dịch nào — từ một lệnh nộp tiền mặt cho đến một khoản giải ngân hàng nghìn tỷ — và biết chính xác tiền đi từ đâu đến đâu.

Bài này đi từ con số 0 (chưa biết Nợ/Có là gì) đến mức "hero" (đọc và viết được bút toán ngân hàng, hiểu vì sao sổ luôn cân).

1. Vấn đề gốc: làm sao ghi lại tiền một cách KHÔNG SAI?

Hãy tưởng tượng bạn ghi sổ chỉ bằng một cột duy nhất: "Hôm nay +10 triệu, hôm sau -3 triệu...". Cách này gọi là single-entry (ghi đơn). Nó có hai khuyết tật chết người:

1. Không tự kiểm tra được: nếu bạn gõ nhầm 100 triệu thành 10 triệu, không có gì báo cho bạn biết.
2. Không trả lời được "tiền đi đâu": bạn biết số dư thay đổi, nhưng không biết nguồn và điểm đến của dòng tiền.

Hạch toán kép ra đời (được hệ thống hóa từ thời Luca Pacioli, thế kỷ 15) để giải quyết cả hai. Ý tưởng cốt lõi cực kỳ đơn giản:

Mỗi sự kiện tiền tệ luôn có ÍT NHẤT hai mặt: tiền ra khỏi một chỗ và vào một chỗ khác. Vì vậy mỗi giao dịch phải được ghi vào ít nhất 2 vế, và TỔNG NỢ luôn bằng TỔNG CÓ.

Đây là một đẳng thức bất biến (invariant). Bất cứ lúc nào tổng Nợ khác tổng Có, bạn biết chắc chắn có lỗi. Đó là "lưới an toàn" mà cả ngành ngân hàng dựa vào.

2. Phương trình kế toán — nền tảng của tất cả

Mọi thứ bắt đầu từ phương trình kế toán cơ bản:

TÀI SẢN  =  NỢ PHẢI TRẢ  +  VỐN CHỦ SỞ HỮU
(Assets) =  (Liabilities) +  (Equity)

• Tài sản (Assets): những gì doanh nghiệp sở hữu / có quyền thu — tiền mặt, tiền gửi tại NHNN, các khoản cho vay khách hàng.
• Nợ phải trả (Liabilities): những gì doanh nghiệp nợ người khác — tiền gửi của khách hàng, tiền vay liên ngân hàng.
• Vốn chủ sở hữu (Equity): phần còn lại thuộc về chủ sở hữu — vốn góp, lợi nhuận giữ lại.

Mở rộng thêm hai nhóm phản ánh kết quả hoạt động:

• Thu nhập (Income/Revenue): làm tăng Vốn chủ sở hữu (ví dụ: thu lãi cho vay).
• Chi phí (Expense): làm giảm Vốn chủ sở hữu (ví dụ: trả lãi tiền gửi).

Hạch toán kép chính là cách giữ cho phương trình này luôn cân sau mỗi giao dịch. Nếu một vế tăng, phải có gì đó ở vế kia tăng theo, hoặc một thành phần khác cùng vế giảm xuống bù lại.

3. Nợ và Có là gì? (Quên "tốt/xấu" đi)

Sai lầm phổ biến nhất của người mới: nghĩ "Nợ = mất tiền/xấu", "Có = nhận tiền/tốt". SAI HOÀN TOÀN.

Nợ (Debit, viết tắt Dr) và Có (Credit, viết tắt Cr) chỉ đơn thuần là hai cột — bên trái và bên phải của một tài khoản. Bản thân chúng không mang nghĩa tốt/xấu, tăng/giảm. Việc chúng làm tăng hay giảm số dư phụ thuộc vào LOẠI tài khoản.

Hãy ghi nhớ quy tắc vàng này:

Ghi Nợ làm tăng tài khoản loại Tài sản và Chi phí. Ghi Có làm tăng tài khoản loại Nợ phải trả, Vốn CSH và Thu nhập. (Và ngược lại để giảm.)

Bảng quy ước tăng/giảm theo loại tài khoản

Mẹo nhớ: Tài sản và Chi phí là "anh em" (Nợ làm tăng). Ba loại còn lại — Nợ phải trả, Vốn, Thu nhập — là "anh em" (Có làm tăng). Lý do sâu xa: Tài sản nằm ở vế trái phương trình kế toán, ba loại kia nằm ở vế phải; quy ước Dr/Cr được thiết kế để vế trái tăng bằng Nợ, vế phải tăng bằng Có — và như vậy hai vế luôn cân.

4. GÓC NHÌN NGÂN HÀNG: vì sao "ghi Có tài khoản khách" lại làm TĂNG số dư của khách?

Đây là điểm gây bối rối nhất cho người mới, và là chỗ phải hiểu thật kỹ.

Khi bạn — với tư cách khách hàng — nhìn vào app ngân hàng và thấy "Ghi Có: +500.000đ", bạn hiểu là tiền vào tài khoản, số dư tăng. Đúng. Nhưng tại sao "Có" (Credit) lại đồng nghĩa với "tăng" ở đây, trong khi ở phần tài sản "Có" là giảm?

Câu trả lời nằm ở góc nhìn của ngân hàng, không phải của bạn:

Tài khoản tiền gửi của khách hàng là một khoản NỢ PHẢI TRẢ của ngân hàng.

Khi bạn gửi 10 triệu vào ngân hàng, số tiền đó không còn "của riêng bạn cất trong két" — ngân hàng cầm tiền của bạn và nợ bạn 10 triệu (bạn có quyền rút ra bất cứ lúc nào). Trên sổ sách của ngân hàng, tài khoản của bạn là một dòng trong nhóm Nợ phải trả.

Mà theo bảng quy ước ở trên: Nợ phải trả tăng khi ghi Có. Vì vậy khi số dư của bạn tăng, ngân hàng ghi Có vào tài khoản tiền gửi của bạn (vì khoản nợ của ngân hàng với bạn tăng lên). Khi bạn rút tiền, ngân hàng ghi Nợ (khoản nợ giảm xuống).

Đây là lý do từ "Credit" trên sao kê của bạn = tiền vào: nó được viết từ góc nhìn kế toán của ngân hàng, và tài khoản của bạn là nợ phải trả của họ. Một khi nắm được điều này, mọi sao kê ngân hàng đều trở nên dễ đọc.

Bạn (khách):     "Tôi có nhiều tiền hơn"  → cảm giác là tài sản tăng
Ngân hàng:       "Tôi nợ khách nhiều hơn" → nợ phải trả tăng → ghi CÓ
                  ↑ Hai góc nhìn, cùng một sự thật.

5. Chart of Accounts (Hệ thống tài khoản kế toán)

Một ngân hàng có hàng trăm nghìn, thậm chí hàng triệu tài khoản. Để quản lý, người ta dùng Chart of Accounts (CoA) — hệ thống tài khoản kế toán: một danh mục có cấu trúc, đặt tên và đánh số cho mọi tài khoản dùng để ghi sổ.

Đặc điểm chính:

• Phân cấp (hierarchy): tài khoản được nhóm theo loại lớn → nhóm con → tài khoản chi tiết. Ví dụ (dùng tên mô tả, không phải số hiệu quy định):

Tài sản
 ├── Tiền mặt và tương đương tiền
 │     ├── Tiền mặt tại quỹ
 │     └── Tiền gửi tại Ngân hàng Trung ương
 └── Cho vay khách hàng
       ├── Cho vay ngắn hạn
       └── Cho vay trung dài hạn
Nợ phải trả
 ├── Tiền gửi khách hàng
 │     ├── Tiền gửi không kỳ hạn
 │     └── Tiền gửi có kỳ hạn
 └── Vay liên ngân hàng
Vốn chủ sở hữu
 ├── Vốn điều lệ
 └── Lợi nhuận giữ lại
Thu nhập
 ├── Thu nhập lãi cho vay
 └── Thu phí dịch vụ
Chi phí
 ├── Chi phí lãi tiền gửi
 └── Chi phí hoạt động

• Mỗi tài khoản gắn với một loại (Tài sản / Nợ phải trả / ...), nhờ đó hệ thống tự biết Nợ làm tăng hay giảm.
• CoA là "từ điển": mọi bút toán đều phải tham chiếu các tài khoản hợp lệ trong CoA. Lập trình viên ngân hàng làm việc với CoA gần như hằng ngày.

Lưu ý: trong bài này tôi cố tình dùng tên mô tả ("Tiền mặt", "Tiền gửi khách hàng", "Thu nhập lãi") thay vì số hiệu tài khoản cụ thể, vì số hiệu phụ thuộc vào chế độ kế toán/quy định của từng nước và từng ngân hàng. Bản chất Nợ/Có thì không đổi.

6. Ví dụ bút toán cụ thể (luôn cân: Tổng Nợ = Tổng Có)

Bây giờ là phần "đào sâu" — ta ghi sổ thật sự. Cách đọc bảng: mỗi dòng là một vế; cột Nợ và cột Có; tổng hai cột phải bằng nhau.

Ví dụ (a) — Khách nộp tiền mặt 10 triệu vào tài khoản

Sự kiện: khách mang 10.000.000đ tiền mặt đến quầy, gửi vào tài khoản của mình.

Tư duy:

• Tiền mặt tại quỹ của ngân hàng tăng 10 triệu → đây là Tài sản, tăng thì ghi Nợ.
• Ngân hàng giờ nợ khách thêm 10 triệu → tài khoản tiền gửi khách là Nợ phải trả, tăng thì ghi Có.

Cân. Nhìn từ phía khách: số dư tăng 10 triệu (vì tài khoản của họ được ghi Có) — đúng như cảm nhận.

Ví dụ (b) — Khách chuyển khoản nội bộ A → B (cùng ngân hàng)

Sự kiện: khách A chuyển 3.000.000đ cho khách B, cả hai đều mở tài khoản tại ngân hàng này.

Tư duy:

• Tài khoản A giảm 3 triệu → A là Nợ phải trả của ngân hàng, giảm thì ghi Nợ.
• Tài khoản B tăng 3 triệu → B là Nợ phải trả, tăng thì ghi Có.
• Lưu ý: tổng tiền mặt / tổng tài sản của ngân hàng không đổi — chỉ là khoản nợ phải trả dịch chuyển từ A sang B. Phương trình kế toán vẫn cân vì hai thay đổi đều nằm trong nhóm Nợ phải trả và bù trừ nhau.

Cân. (Nếu chuyển liên ngân hàng, sẽ phức tạp hơn vì còn liên quan tài khoản thanh toán tại NHTW — sẽ bàn ở các bài sau.)

Ví dụ (c1) — Ngân hàng giải ngân khoản vay 100 triệu

Sự kiện: ngân hàng duyệt cho khách vay 100.000.000đ và giải ngân vào tài khoản tiền gửi của khách.

Tư duy:

• Ngân hàng có thêm một khoản phải thu từ khách (cho vay) → "Cho vay khách hàng" là Tài sản, tăng thì ghi Nợ.
• Tiền được bơm vào tài khoản tiền gửi của khách → Nợ phải trả tăng → ghi Có.

Điều thú vị: giải ngân làm cả tổng tài sản và tổng nợ phải trả của ngân hàng cùng tăng 100 triệu. Đây chính là cơ chế ngân hàng "tạo tiền" qua tín dụng — bút toán làm xuất hiện đồng thời một tài sản (khoản vay) và một khoản nợ (tiền gửi mới).

Ví dụ (c2) — Ngân hàng thu lãi vay 1 triệu

Sự kiện: đến kỳ, ngân hàng thu 1.000.000đ tiền lãi bằng cách trích từ tài khoản tiền gửi của khách.

Tư duy:

• Tài khoản tiền gửi của khách giảm 1 triệu → Nợ phải trả giảm → ghi Nợ.
• Ngân hàng ghi nhận thu nhập lãi → Thu nhập tăng → ghi Có.

Cân. Thu nhập tăng → cuối kỳ làm tăng Vốn chủ sở hữu (lợi nhuận), giữ phương trình kế toán cân ở cấp tổng thể.

Nhận xét chung: trong mọi ví dụ, tổng cột Nợ = tổng cột Có. Đó không phải sự trùng hợp — đó là quy luật. Một bút toán không cân là một bút toán sai, hệ thống ngân hàng sẽ từ chối ghi.

7. Luồng một giao dịch đi vào GL (sơ đồ)

Khi một giao dịch xảy ra (ví dụ nộp tiền mặt), nó đi qua một chuỗi bước trước khi nằm yên trong Sổ cái:

Điểm mấu chốt: kiểm tra cân (Nợ = Có) xảy ra TRƯỚC khi ghi. Nếu không cân, bút toán bị chặn ngay từ đầu. Đây là tuyến phòng thủ đầu tiên đảm bảo toàn vẹn dữ liệu kế toán.

8. GL (Sổ cái tổng hợp) vs Sổ phụ (Subsidiary Ledger)

Một câu hỏi tự nhiên: ngân hàng có hàng triệu khách, chẳng lẽ Sổ cái có hàng triệu dòng "Tiền gửi khách hàng"?

Câu trả lời: người ta tách làm hai tầng.

Tài khoản GL "Tiền gửi khách hàng" được gọi là tài khoản kiểm soát (control account): số dư của nó phải bằng tổng số dư của tất cả tài khoản khách trong sổ phụ. Nếu hai con số không khớp → có lỗi ở đâu đó, phải tìm và sửa.

Lợi ích của thiết kế này:

• GL gọn nhẹ, dùng cho báo cáo và kiểm toán.
• Sổ phụ chi tiết, phục vụ tác nghiệp hằng ngày (xem số dư, lịch sử, sao kê).
• Hai tầng đối chiếu chéo lẫn nhau, tạo thêm một lớp kiểm tra tính đúng đắn.

9. Vì sao GL phải cân mỗi cuối ngày (EOD Reconciliation)

Cuối mỗi ngày làm việc, hệ thống ngân hàng chạy quy trình End-of-Day (EOD) và thực hiện hàng loạt phép đối chiếu (reconciliation). Hai phép quan trọng nhất:

1. Tổng Nợ toàn GL = Tổng Có toàn GL. Vì mỗi bút toán đều cân, tổng của toàn bộ bút toán trong ngày cũng phải cân. Nếu lệch dù 1 đồng → chắc chắn có lỗi (bút toán treo, lỗi làm tròn, lỗi hệ thống) và phải truy ra trước khi "đóng ngày".
2. GL khớp sổ phụ. Số dư mỗi tài khoản kiểm soát trong GL = tổng số dư sổ phụ tương ứng.

Vì sao bắt buộc làm mỗi ngày, không để dồn?

• Phát hiện lỗi sớm: lỗi để càng lâu càng khó truy vết (hôm nay 1 bút toán sai dễ tìm, sau một tháng là hàng triệu bút toán).
• Cơ sở cho báo cáo: số dư cuối ngày là điểm xuất phát cho ngày hôm sau và cho báo cáo gửi cơ quan quản lý.
• Phát hiện gian lận / sự cố: chênh lệch bất thường có thể là dấu hiệu của lỗi nghiêm trọng hoặc hành vi gian lận.

Nói cách khác, "GL cân" không phải mục tiêu trang trí — nó là bằng chứng rằng mọi đồng tiền đều được giải thích đầy đủ: vào từ đâu, ra đi đâu.

10. Minh họa bằng SQL trên sandbox

Trong môi trường thực, GL được ghi bằng các bảng bút toán phức tạp. Nhưng để cảm nhận khái niệm Nợ/Có, ta dùng bảng demo đơn giản trong SQL Builder:

• accounts(id, customer_id, account_no, balance, currency)
• transactions(id, account_id, amount, kind ['credit'|'debit'], created_at)

Truy vấn dưới đây tính tổng phát sinh Có và Nợ theo từng tài khoản:

▶ Chạy được trong SQL Builder

SELECT a.account_no,
       SUM(CASE WHEN t.kind = 'credit' THEN t.amount ELSE 0 END) AS tong_co,
       SUM(CASE WHEN t.kind = 'debit'  THEN t.amount ELSE 0 END) AS tong_no
FROM accounts a
LEFT JOIN transactions t ON t.account_id = a.id
GROUP BY a.account_no
ORDER BY a.account_no;

Mối liên hệ với khái niệm Nợ/Có kế toán

Trong bảng demo này, mỗi giao dịch chỉ ghi một dòng với kind là 'credit' hoặc 'debit', xét từ góc nhìn tài khoản tiền gửi của khách hàng:

• kind = 'credit' → tiền vào tài khoản khách → số dư khách tăng. Đúng với quy ước: tài khoản tiền gửi là Nợ phải trả của ngân hàng, ghi Có (credit) làm tăng nợ phải trả = tăng số dư khách.
• kind = 'debit' → tiền ra khỏi tài khoản khách → số dư khách giảm. Ghi Nợ (debit) làm giảm nợ phải trả của ngân hàng.

Đây là lý do trong bảng transactions, một lần nộp tiền của khách thường mang kind = 'credit', còn rút tiền mang kind = 'debit'.

⚠️ Lưu ý quan trọng: đây là dữ liệu minh họa đơn giản, không phải GL thật. GL thật ghi đủ hai vế cho mỗi giao dịch (Nợ vế này, Có vế kia, hai con số bằng nhau). Bảng demo chỉ lưu một vế nhìn từ tài khoản khách, nên nó không tự cân theo nghĩa hạch toán kép. Nó hữu ích để luyện tư duy credit/debit, nhưng đừng nhầm với sổ cái sản xuất.

Một bút toán GL "hai vế" đầy đủ (như ví dụ nộp tiền ở mục 6) nếu viết dưới dạng SQL sẽ phải ghi vào bảng dòng bút toán có cả tài khoản Nợ và tài khoản Có. Bảng đó không tồn tại trong sandbox, nên bút toán dưới đây chỉ để tham khảo:

-- (minh hoạ, không chạy trong sandbox)
-- Một bút toán GL chuẩn cho lần nộp tiền mặt 10 triệu:
INSERT INTO gl_entries (entry_id, account, debit, credit) VALUES
  (1001, 'Tiền mặt tại quỹ',       10000000, 0),
  (1001, 'Tiền gửi khách hàng',    0,        10000000);
-- Ràng buộc bất biến: SUM(debit) = SUM(credit) cho mỗi entry_id.

Tóm tắt

• Hạch toán kép: mỗi giao dịch ghi ít nhất 2 vế; Tổng Nợ luôn = Tổng Có. Đây là bất biến giúp tự phát hiện lỗi.
• Nợ/Có không phải tốt/xấu — chỉ là hai cột. Tác dụng tăng/giảm phụ thuộc loại tài khoản: Tài sản & Chi phí tăng khi ghi Nợ; Nợ phải trả, Vốn CSH & Thu nhập tăng khi ghi Có.
• Tài khoản tiền gửi của khách là Nợ phải trả của ngân hàng — nên "ghi Có" làm tăng số dư khách. Đây là chìa khóa đọc hiểu mọi sao kê.
• Chart of Accounts là danh mục phân cấp mọi tài khoản, gắn mỗi tài khoản với một loại.
• GL (sổ cái tổng hợp) gộp theo tài khoản; sổ phụ chi tiết tới từng khách. Tài khoản kiểm soát trong GL phải bằng tổng sổ phụ.
• EOD reconciliation: cuối ngày phải chứng minh GL cân (Nợ=Có) và GL khớp sổ phụ, để phát hiện lỗi/gian lận sớm.

Tự kiểm tra

1. Vì sao khi bạn nộp tiền vào ngân hàng, ngân hàng lại ghi Có vào tài khoản của bạn dù số dư của bạn tăng? (Gợi ý: góc nhìn của ai?)
2. Một bút toán ghi Nợ "Cho vay khách hàng" 50 triệu và ghi Có "Tiền gửi khách hàng" 50 triệu — đây là nghiệp vụ gì, và vì sao nó làm cả tài sản lẫn nợ phải trả của ngân hàng cùng tăng?
3. Lập bút toán (bảng Nợ/Có) cho nghiệp vụ: khách rút 2 triệu tiền mặt từ tài khoản.
4. Phân biệt GL và sổ phụ. "Tài khoản kiểm soát" nghĩa là gì?
5. Nếu cuối ngày tổng Nợ của GL lệch tổng Có 1.000đ, điều đó nói lên điều gì và vì sao không được bỏ qua?
6. Trong bảng transactions của sandbox, vì sao một lần khách nộp tiền lại có kind = 'credit'? Bảng này có phải GL thật không, vì sao?

Đọc tiếp

Bài 4 — Tiền gửi