Kế toán NH 3 — Sổ cái (GL) & sổ phụ (subledger)

13 thg 7, 2026 3 lượt xem

#banking

#accounting

#subledger

#general-ledger

#reconciliation

#posting

Sổ cái (GL) và sổ phụ (subledger) — hai tầng ghi sổ của ngân hàng

Ở bài Ghi sổ kép & COA chúng ta đã thấy mọi giao dịch đều đẻ ra các dòng bút toán Nợ/Có cân đối, gắn với một mã tài khoản kế toán trong bảng danh mục (Chart of Accounts). Nhưng có một câu hỏi thực tế mà bài đó chưa trả lời: một ngân hàng có hàng chục triệu tài khoản khách hàng, vậy sổ cái của nó có hàng chục triệu dòng số dư không? Câu trả lời là không — và lời giải chính là kiến trúc hai tầng: sổ phụ (subledger) ở dưới, sổ cái tổng hợp (General Ledger — GL) ở trên.

Hiểu rõ ranh giới giữa hai tầng này là điều kiện tiên quyết để làm được ba việc cốt lõi của dân Data ngân hàng: đọc đúng báo cáo tài chính, làm đối soát, và giải thích được vì sao "số trên GL" lại lệch "số trên sổ chi tiết". Bài này đi từ khái niệm, tới luồng posting, tới cơ chế entry trong core banking (nối T24 core ops), và kết ở kiểm soát đối chiếu.

Vì sao phải tách sổ cái khỏi sổ phụ

Hãy hình dung một ngân hàng có 5 triệu tài khoản tiền gửi thanh toán. Về mặt kế toán, toàn bộ 5 triệu tài khoản đó chỉ là một khoản mục duy nhất trên bảng cân đối: "Tiền gửi không kỳ hạn của khách hàng cá nhân" — một dòng Nợ phải trả của ngân hàng. Kế toán tài chính chỉ cần tổng số tiền ngân hàng đang nợ nhóm khách hàng đó, không quan tâm tài khoản nào của ai.

Ngược lại, bộ phận vận hành bắt buộc phải biết từng đồng của từng khách hàng: tài khoản của anh A đang có bao nhiêu, có bị phong tỏa không, lãi cộng dồn tới đâu. Đó là hai nhu cầu khác nhau về bản chất, nên tách thành hai tầng:

Subledger (sổ phụ / sổ chi tiết): ghi chi tiết tới mức đối tượng vận hành — theo từng khách hàng, từng hợp đồng, từng tài khoản, từng giao dịch. Ví dụ điển hình: sổ tiền gửi (mỗi tài khoản tiền gửi một dòng số dư), sổ cho vay (mỗi khế ước/hợp đồng vay một dòng dư nợ gốc + lãi), sổ thẻ, sổ tài sản cố định, sổ phải thu. Subledger là nơi "sống" của nghiệp vụ.
General Ledger (GL / sổ cái tổng hợp): ghi ở mức tài khoản kế toán tổng hợp, mỗi dòng là một mã trong COA (ví dụ mã "Tiền gửi KKH cá nhân VND"). GL gọn — chỉ vài nghìn tới vài chục nghìn tài khoản GL — đủ để lập báo cáo tài chính và hợp nhất số liệu.

Nguyên tắc vàng nối hai tầng: tổng số dư của mọi tài khoản trong một subledger phải bằng số dư của (các) tài khoản GL tương ứng. Tài khoản GL đóng vai trò "control account" (tài khoản kiểm soát) cho subledger đứng sau nó. Nếu tổng sổ tiền gửi = 12.000 tỷ thì dòng GL "Tiền gửi KKH" cũng phải đúng 12.000 tỷ. Khi hai con số này lệch nhau, ta gọi đó là một break — và đó là tín hiệu có sai sót cần điều tra.

Luồng posting: từ giao dịch tới GL

Posting là hành động ghi một bút toán vào sổ. Trong ngân hàng hiện đại, luồng đi qua nhiều chặng:

Hệ nghiệp vụ sinh giao dịch: khách chuyển khoản, nộp tiền mặt, hệ thống tính lãi cuối ngày… Mỗi giao dịch được xử lý ở module sản phẩm (thanh toán, tiền gửi, cho vay, thẻ).
Sinh entry (bút toán): module dịch giao dịch thành các dòng Nợ/Có cân đối, mỗi dòng gắn tài khoản (số tài khoản khách hoặc tài khoản nội bộ) và mã kế toán.
Cập nhật subledger: số dư của tài khoản khách hàng liên quan được cập nhật ngay (thường real-time).
Post/summarize lên GL: các entry được gom (summarize) theo mã GL rồi dồn lên sổ cái. Đây là điểm mấu chốt: GL thường không nhận từng dòng chi tiết mà nhận số tổng đã gộp theo mã tài khoản GL trong kỳ — nếu không GL sẽ phình to bằng subledger, mất hết ý nghĩa "gọn".

Về nhịp posting, có hai mô hình cùng tồn tại:

Real-time: subledger (số dư tài khoản khách) cập nhật tức thì để phục vụ vấn tin, hạn mức, ATM.
Batch / gộp cuối ngày: việc dồn lên GL và cập nhật số tổng GL thường chạy theo mẻ, điển hình trong quy trình cuối ngày (nối COB). GL trong ngày có thể chỉ là số "chạy tạm", số chốt là sau khi đóng sổ ngày.

Ba loại ngày dễ nhầm

Một giao dịch có tới ba mốc thời gian, và nhầm lẫn giữa chúng là nguyên nhân đối soát lệch phổ biến nhất:

Transaction date (ngày giao dịch): ngày người dùng thực hiện thao tác.
Posting date / booking date (ngày hạch toán): ngày bút toán được ghi vào sổ — quyết định giao dịch thuộc kỳ kế toán nào. Một giao dịch nhập lúc 23h55 nhưng sau giờ cut-off có thể được post sang ngày làm việc kế tiếp.
Value date (ngày giá trị): ngày giao dịch có hiệu lực về tính lãi và số dư khả dụng. Value date có thể ở quá khứ (back-value) hoặc tương lai (forward-value), nên số dư sổ sách (book balance) có thể khác số dư theo value (cleared balance) tại cùng một thời điểm.

Ghi nhớ: posting date định kỳ báo cáo; value date định lãi. Khi số dư GL ≠ số dư khả dụng, nghi vấn đầu tiên là chênh lệch value date.

Entry trong core banking (T24)

Trong Temenos T24, cơ chế trên hiện diện rất rõ qua các file entry. Ở T24 core operations đã giới thiệu, ở đây ta gắn chúng vào mô hình GL ↔ subledger:

STMT.ENTRY — bút toán sao kê, gắn với tài khoản khách hàng cụ thể (một ACCOUNT). Đây chính là dữ liệu subledger ở tầng tài khoản: mỗi lần tài khoản khách bị ghi Nợ/Có, một STMT.ENTRY ra đời. Cộng dồn STMT.ENTRY của một tài khoản ra số dư tài khoản đó.
CATEG.ENTRY — bút toán theo category (loại/mục kế toán), không gắn vào một tài khoản khách riêng lẻ mà vào một mục nội bộ như thu nhập lãi, chi phí phí, tài khoản trung gian. Đây là dạng bút toán nội bộ (P&L, tài khoản GL nội bộ).

Điểm cần phân biệt là bút toán khách vs bút toán nội bộ:

Ghi Nợ/Có tài khoản khách → sinh STMT.ENTRY (subledger tài khoản).
Vế đối ứng vào mục thu nhập/chi phí/nội bộ → sinh CATEG.ENTRY.

Ví dụ thu phí chuyển khoản: STMT.ENTRY ghi Nợ tài khoản khách (trừ phí), CATEG.ENTRY ghi Có mục "thu nhập phí dịch vụ".

Cuối cùng, T24 chạy RE consolidation (Reporting Entry consolidation — họ file RE.CONSOL.*) để gom các entry theo mã GL và dồn lên sổ cái. Đây chính là bước "summarize lên GL" ở phần trước, được cụ thể hóa: entry chi tiết ở subledger → consolidation theo COA/category → số dư GL. Với dân Data, cần nhớ: muốn số chi tiết thì đọc STMT.ENTRY/CATEG.ENTRY; muốn số tổng hợp khớp báo cáo thì đọc lớp consolidation/GL. Trộn hai nguồn mà không hiểu ranh giới là công thức của những con số "gần đúng mà không khớp".

Sơ đồ luồng: giao dịch → subledger → GL → báo cáo

Đối chiếu GL ↔ subledger (reconciliation)

Đây là kiểm soát then chốt của toàn bộ hệ thống ghi sổ, và là chỗ dân Data hay được gọi vào cứu hỏa. Nguyên tắc: với mỗi tài khoản GL đóng vai control account, ta lấy tổng số dư mọi tài khoản/hợp đồng trong subledger tương ứng và so với số dư GL. Chúng phải bằng nhau tuyệt đối.

ĐỐI CHIẾU GL ↔ SUBLEDGER — Tiền gửi KKH cá nhân VND   (minh hoạ)
Ngày đối chiếu: 2026-06-30

  Số dư GL (control account 4211-VND) ........  12.045.300.000
  Tổng subledger (sum số dư tài khoản KH) ....  12.045.300.000
  --------------------------------------------------------------
  Chênh lệch (break) .........................              0    ✔ khớp


ĐỐI CHIẾU GL ↔ SUBLEDGER — Cho vay ngắn hạn VND        (minh hoạ)

  Số dư GL (control account 2111-VND) ........   8.900.000.000
  Tổng subledger (sum dư nợ gốc hợp đồng) ....   8.899.100.000
  --------------------------------------------------------------
  Chênh lệch (break) .........................         900.000   ✖ CẦN ĐIỀU TRA

Khi có break, quy trình điều tra chuẩn:

Khoanh vùng thời điểm khớp gần nhất — break xuất hiện từ ngày nào? So sánh biến động GL và biến động subledger từng ngày để tìm ngày lệch bắt đầu.
Soi bút toán một vế — break thường do một bút toán ghi vào GL nhưng không vào subledger (hoặc ngược lại): ví dụ điều chỉnh thủ công vào GL, hoặc một giao dịch subledger chưa consolidate.
Kiểm value date / posting date — giao dịch back-value hoặc post lệch kỳ làm hai tầng chốt số ở hai mốc khác nhau.
Kiểm suspense — có bút toán bị đẩy vào tài khoản treo thay vì subledger đích.

Chi tiết quy trình kiểm soát và tự động hóa đối soát nằm ở Đối soát & kiểm soát.

Suspense & clearing accounts (tài khoản treo và trung gian)

Không phải giao dịch nào cũng khớp ngay hai vế. Khi hệ thống chưa biết đối ứng cuối cùng, nó tạm ghi vào một tài khoản treo (suspense account) để giữ cho bút toán vẫn cân đối, chờ xử lý sau. Clearing account (tài khoản trung gian/thanh toán bù trừ) thì dùng cho các luồng đi qua nhiều bước — ví dụ tiền liên ngân hàng nằm ở clearing cho tới khi đối tác xác nhận.

BÚT TOÁN QUA SUSPENSE — tiền chuyển đến chưa xác định người hưởng   (minh hoạ)

Bước 1 — nhận tiền, chưa biết tài khoản đích:
  Nợ  Tài khoản Nostro (tiền về) .............  50.000.000
      Có  Suspense - chuyển đến chờ xử lý ....           50.000.000

Bước 2 — sau khi tra soát, xác định người hưởng:
  Nợ  Suspense - chuyển đến chờ xử lý ........  50.000.000
      Có  Tài khoản khách hàng B .............           50.000.000

  => Số dư suspense sau xử lý = 0  (đã "làm sạch")

Nguyên tắc quản trị: tài khoản suspense/clearing phải được theo dõi và làm sạch (clear) thường xuyên, lý tưởng là về 0 cuối ngày hoặc trong thời hạn quy định. Một suspense có số dư "già" (aging cao) là dấu hiệu giao dịch kẹt, và cũng là nguồn break kinh điển giữa GL và subledger — vì tiền đã vào GL (qua tài khoản treo) nhưng chưa vào subledger đích. Báo cáo aging của suspense là một dataset mà đội Data thường phải dựng.

Multi-currency & multi-entity

Đa tiền tệ (multi-currency): GL của ngân hàng ghi theo nguyên tệ — nghĩa là mỗi tài khoản GL tồn tại theo từng đồng tiền (VND, USD, EUR…). Để lên báo cáo hợp nhất bằng đồng báo cáo (thường VND), số dư nguyên tệ được quy đổi theo tỷ giá. Từ đó sinh ra chênh lệch tỷ giá (FX revaluation): khi tỷ giá thay đổi, giá trị quy đổi của số dư ngoại tệ đổi theo, phần chênh được hạch toán vào một mục P&L/vốn riêng. Đây là lý do một tài khoản USD "không phát sinh giao dịch" mà số dư quy đổi VND vẫn đổi qua các ngày.

Đa pháp nhân (multi-entity / multi-company): một cài đặt core có thể phục vụ nhiều pháp nhân/chi nhánh hạch toán độc lập (nối phần multi-company trong T24 core ops). Mỗi entity có bộ GL riêng; báo cáo tập đoàn cần hợp nhất (consolidation) qua các pháp nhân, loại trừ giao dịch nội bộ (intercompany). Với dân Data, luôn phải hỏi: số này thuộc entity nào, tính bằng đồng gì, đã quy đổi chưa — ba câu hỏi này chặn phần lớn lỗi báo cáo.

Đóng sổ (close)

Sổ sách được chốt theo chu kỳ:

Đóng ngày (end-of-day): chạy trong quy trình cuối ngày (nối COB) — tính lãi, dồn entry lên GL, chốt số dư ngày, và mang số dư sang ngày làm việc kế tiếp làm số dư đầu ngày. Số GL sau COB mới là số chính thức của ngày.
Đóng kỳ (period/month/year-end): chốt số kỳ, tính các bút toán điều chỉnh, revaluation, và kết chuyển. Cuối năm, các tài khoản P&L được kết chuyển (roll-up) về lợi nhuận chưa phân phối, số dư về 0 để mở kỳ mới; các tài khoản bảng cân đối thì số dư mang sang liên tục.

Trước và sau mỗi lần đóng sổ, đối chiếu GL ↔ subledger là thủ tục bắt buộc — vì đóng sổ với một break chưa giải thích được nghĩa là chôn sai sót vào số dư mang sang.

Vai trò dữ liệu

Với đội Data Warehouse / báo cáo, GL và các file entry là nguồn sự thật kế toán:

Báo cáo tài chính (Báo cáo tài chính) được dựng chủ yếu từ số dư GL theo mã COA — vì GL đã là mức tổng hợp khớp với khoản mục báo cáo.
Đối soát và các phân tích chi tiết lại cần subledger + entry (STMT.ENTRY, CATEG.ENTRY) để truy tới từng khách hàng, từng giao dịch.
Nguyên tắc mô hình hóa: giữ rõ grain của từng nguồn — GL là grain "mã tài khoản × ngày × entity × tiền tệ"; entry là grain "giao dịch". Đừng cộng entry rồi kỳ vọng bằng GL nếu chưa xử lý đúng consolidation, value date và suspense.

Chi tiết cách khai thác dữ liệu kế toán cho DW nằm ở Dữ liệu kế toán.

Use case thực tế: chênh lệch GL vs sổ tiền gửi

Bối cảnh: cuối tháng, báo cáo cân đối cho thấy dòng GL "Tiền gửi KKH cá nhân VND" = 12.045.3 tỷ, nhưng tổng số dư sổ tiền gửi (sum số dư từng tài khoản) = 12.044.4 tỷ. Break 900 triệu. Kế toán chặn đóng sổ, gọi đội Data trích số điều tra.

Cách điều tra thực tế:

Dựng chuỗi khớp theo ngày: lấy số dư GL cuối ngày và tổng subledger cuối ngày cho 30 ngày. Phát hiện hai tầng khớp tới ngày 27, lệch từ ngày 28 — thu hẹp vùng nghi vấn còn một ngày.
Soi entry ngày 28: liệt kê mọi bút toán chạm control account GL 4211-VND và mọi bút toán chạm tài khoản tiền gửi trong subledger. Đối chiếu hai danh sách.
Tìm bút toán một vế: thấy một bút toán điều chỉnh thủ công 900 triệu ghi thẳng vào GL 4211 (do vận hành sửa số), nhưng không có STMT.ENTRY đối ứng trên tài khoản khách nào — tức GL bị chỉnh mà subledger không đổi.
Kiểm giả thuyết value date: loại trừ — không có giao dịch back-value trong ngày liên quan tới con số này.
Kết luận & xử lý: break không phải do dữ liệu subledger sai, mà do một bút toán chỉnh tay vào GL không đi qua nghiệp vụ. Hoặc đảo bút toán chỉnh tay, hoặc ghi bổ sung đúng vào tài khoản khách để hai tầng khớp lại. Sau xử lý, break về 0.

Bài học: khi GL ≠ subledger, thủ phạm thường là bút toán chỉ chạm một tầng (chỉnh tay vào GL, hoặc giao dịch subledger chưa consolidate, hoặc kẹt ở suspense), chứ hiếm khi là "toàn bộ subledger sai". Kỹ thuật "khoanh ngày lệch → soi entry một vế" giải quyết phần lớn ca.

Ghi nhớ

Hai tầng: subledger ghi chi tiết theo khách hàng/hợp đồng/giao dịch (sổ tiền gửi, sổ cho vay, sổ thẻ); GL ghi tổng hợp theo mã COA. Tách để GL gọn cho báo cáo, subledger chi tiết cho vận hành.
Ràng buộc vàng: tổng subledger = số dư GL control account tương ứng. Lệch = break, phải điều tra.
Posting: subledger thường real-time, GL thường gộp/summarize (batch, chốt trong COB). Phân biệt transaction date / posting date / value date — posting định kỳ báo cáo, value định lãi.
T24: STMT.ENTRY = bút toán tài khoản khách (subledger); CATEG.ENTRY = bút toán nội bộ/P&L; RE consolidation gom entry lên GL.
Suspense/clearing: giữ bút toán cân đối khi chưa khớp đối ứng; phải theo dõi aging và làm sạch — nguồn break kinh điển.
Multi-currency/multi-entity: GL theo nguyên tệ + quy đổi (FX revaluation); nhiều pháp nhân cần hợp nhất, loại trừ nội bộ. Luôn hỏi: entity nào, tiền gì, quy đổi chưa.
Dữ liệu: BCTC dựng từ GL; đối soát/chi tiết dựng từ subledger+entry. Đừng cộng entry mà kỳ vọng bằng GL nếu chưa xử đúng consolidation/value date/suspense.