Nghiệp vụ lõi & kế toán trong T24 — từ giao dịch đến sổ cái

Ở các bài trước chúng ta đã đi qua tổng quan T24, triết lý parameter-driven và mô hình dữ liệu. Bài này bước vào phần "ruột" của hệ thống: những application mà giao dịch thực sự diễn ra, và cỗ máy kế toán đứng phía sau biến mỗi giao dịch thành các dòng bút toán cân đối trên sổ cái. Nếu bạn làm Data Warehouse, đối soát (reconciliation) hay báo cáo tài chính, đây chính là vùng đất bạn sẽ sống ở đó phần lớn thời gian — vì mọi con số cuối cùng đều truy ngược về những file entry mà bài này mô tả.

Bốn "diễn viên chính" là CUSTOMER, ACCOUNT, FUNDS.TRANSFER (FT) và TELLER — chúng tạo ra hầu hết lưu lượng giao dịch hằng ngày. Phía sau là lớp kế toán: STMT.ENTRY, CATEG.ENTRY, RE.CONSOL.SPEC.ENTRY và bộ máy dồn lên General Ledger (GL).

CUSTOMER — hồ sơ khách hàng ở trung tâm

CUSTOMER là application lưu hồ sơ khách hàng, và nó là điểm tham chiếu trung tâm của gần như mọi thứ khác trong T24. Một tài khoản phải thuộc về một khách hàng; một khoản vay, một sổ tiết kiệm, một giao dịch chuyển tiền — tất cả đều móc về CUSTOMER.

@ID của bản ghi CUSTOMER là customer number (mã số khách hàng), một con số do hệ thống sinh ra. Đây là khóa mà mọi module khác dùng để trỏ về. Trong bản ghi CUSTOMER bạn sẽ thấy:

• Thông tin định danh: tên, ngày sinh / ngày thành lập, quốc tịch, phân biệt cá nhân (individual) hay tổ chức (corporate) qua các field như SECTOR, INDUSTRY, TARGET.
• Fields phục vụ KYC/AML: giấy tờ định danh, RESIDENCE, NATIONALITY, tình trạng chính trị (PEP), phân loại rủi ro.
• Phân khúc (segmentation): nhóm khách hàng để định giá sản phẩm, ưu đãi, báo cáo.
• Quan hệ (relationships): T24 cho phép mô hình hóa quan hệ giữa các khách hàng (ví dụ vợ/chồng, công ty mẹ/con, người bảo lãnh) qua RELATION.CODE và các file quan hệ. Điều này quan trọng khi tính toán tổng dư nợ nhóm (group exposure).

Với đội Data, CUSTOMER là bảng chiều (dimension) quan trọng bậc nhất. Mọi phân tích theo khách hàng, mọi báo cáo NPL theo nhóm liên quan, mọi hồ sơ 360 độ đều bắt đầu từ đây. Vì CUSTOMER được tham chiếu ở khắp nơi, chất lượng dữ liệu của nó ảnh hưởng dây chuyền tới toàn bộ downstream.

ACCOUNT — tài khoản và số dư online

ACCOUNT là application lưu tài khoản: tài khoản thanh toán (current), tiết kiệm không kỳ hạn, tài khoản nội bộ của ngân hàng (internal account) và các loại khác. Đây là nơi "số tiền nằm ở đâu" được ghi nhận.

Đặc điểm cần nhớ:

• @ID chính là số tài khoản (account number). Trong nhiều triển khai, số tài khoản này được sinh theo cấu trúc mã hóa cả loại sản phẩm và chi nhánh.
• Bản ghi ACCOUNT liên kết tới CUSTOMER (chủ tài khoản, qua field CUSTOMER), tới CATEGORY (loại sản phẩm/mục đích tài khoản), và tới CURRENCY (loại tiền tệ).
• CATEGORY là một khái niệm trung tâm sẽ quay lại ở phần kế toán: nó phân loại tài khoản (ví dụ dải số cho tài khoản thanh toán cá nhân, dải khác cho tiết kiệm, dải khác cho tài khoản nội bộ P&L). Category quyết định tài khoản này được gom vào đâu khi lên sổ cái.
• Số dư online (real-time): khi một giao dịch được post, số dư trên ACCOUNT cập nhật ngay. T24 lưu nhiều loại số dư: ONLINE.ACTUAL.BAL (số dư thực tế), ONLINE.CLEARED.BAL (số dư khả dụng đã clear), working balance, v.v. Các loại này rất hay bị nhầm trong đối soát — số dư khả dụng ≠ số dư sổ sách khi có bút toán chờ giá trị (value date tương lai) hoặc phong tỏa.

ACCOUNT không tự "làm" giao dịch — nó là đối tượng bị tác động. Người làm giao dịch là FT, TELLER, và các module sản phẩm (AA/Loans/Deposits — xem Arrangement Architecture).

FUNDS.TRANSFER (FT) — cỗ máy sinh giao dịch số một

FUNDS.TRANSFER là application chuyển tiền và thanh toán: chuyển khoản nội bộ giữa hai tài khoản trong cùng ngân hàng, chuyển liên ngân hàng, thanh toán ra ngoài, thu phí, và vô số biến thể khác. Trong hầu hết các ngân hàng, FT là nơi phát sinh nhiều bản ghi giao dịch nhất — nên nó cũng là bảng "nóng" nhất với đội Data.

Các field cốt lõi của một bản ghi FT:

• DEBIT.ACCT.NO — tài khoản ghi Nợ (tiền đi ra).
• CREDIT.ACCT.NO — tài khoản ghi Có (tiền đi vào).
• DEBIT.AMOUNT / CREDIT.AMOUNT / DEBIT.CURRENCY / CREDIT.CURRENCY — số tiền và loại tiền hai vế (khác nhau khi có chuyển đổi ngoại tệ).
• DEBIT.VALUE.DATE / CREDIT.VALUE.DATE — ngày giá trị, tức ngày giao dịch có hiệu lực về mặt tính lãi/số dư (có thể khác ngày book).
• CHARGE.* — phí giao dịch, ai chịu phí (OUR/BEN/SHA), hạch toán vào category thu nhập phí nào.
• TRANSACTION.TYPE — quyết định bản chất giao dịch và bộ quy tắc hạch toán áp dụng.

Điểm quan trọng về kiến trúc: FT không tự viết bút toán bằng code cứng. Nó khai báo ý định (nợ tài khoản này, có tài khoản kia, thu phí này), rồi lớp kế toán parameter-driven dịch ý định đó thành entry. Cùng một application FT, cấu hình khác nhau sẽ sinh bút toán khác nhau mà không cần sửa mã.

TELLER — giao dịch quầy tiền mặt

TELLER là application xử lý giao dịch tại quầy có yếu tố tiền mặt: khách nộp tiền mặt vào tài khoản, rút tiền mặt, thu/chi tiền mặt cho các nghiệp vụ khác. Điểm phân biệt với FT: TELLER luôn có một vế là tiền mặt (till/vault của giao dịch viên), trong khi FT thường là chuyển khoản giữa hai tài khoản sổ sách.

Các khái niệm gắn với TELLER:

• TELLER.ID — định danh giao dịch viên / quầy.
• Till và Vault: till là két/ngăn tiền mặt của từng giao dịch viên; vault là kho quỹ chi nhánh. Mỗi lần nộp/rút tiền mặt, một bên là tài khoản khách, bên kia là tài khoản tiền mặt của till. Cuối ngày, till phải được cân quỹ (balancing) — số tiền mặt vật lý phải khớp với số dư sổ sách của till. Đây là một trong những hoạt động đối soát nội bộ căn bản nhất của ngân hàng.
• TELLER cũng khai báo ý định nợ/có, và cỗ máy kế toán sinh entry y hệt như FT.

Kế toán & bút toán kép — trái tim của hệ thống

Đây là phần cốt lõi cần nắm thật chắc. Mỗi giao dịch tài chính trong T24 đều tuân thủ nguyên lý ghi sổ kép (double-entry): tổng Nợ luôn bằng tổng Có. T24 không cho phép post một giao dịch mất cân đối — đây là bất biến (invariant) của toàn hệ thống.

Cơ chế: application nghiệp vụ (FT, TELLER, sản phẩm...) không ghi thẳng vào sổ cái, mà sinh ra các "entry" lưu trong file chuyên biệt. Ba loại entry chính, phân biệt theo cái gì bị tác động:

1. STMT.ENTRY — bút toán vào tài khoản khách/nội bộ

STMT.ENTRY (Statement Entry) ghi mọi giao dịch có Nợ hoặc Có vào một tài khoản — tài khoản khách hàng hoặc tài khoản nội bộ (internal account). Đây là những entry sẽ lên sao kê (statement) của khách. Nếu số dư một tài khoản thay đổi, gần như chắc chắn có một STMT.ENTRY đứng sau.

Mỗi STMT.ENTRY mang các trường phân tích quý giá: số tài khoản (ACCOUNT.NUMBER), số tiền, loại tiền, value date, booking date, TRANSACTION.CODE, mã tham chiếu giao dịch gốc, CO.CODE (công ty/chi nhánh). Với DWH, STMT.ENTRY là bảng transaction fact quan trọng nhất.

2. CATEG.ENTRY — bút toán theo category / P&L nội bộ

CATEG.ENTRY (Category Entry) ghi những bút toán không thuộc về tài khoản của một khách hàng cụ thể, mà tác động tới lãi/lỗ (P&L) hoặc các đầu mục nội bộ của ngân hàng theo CATEGORY. Ví dụ điển hình: phí và hoa hồng (charges, commission) thu được từ giao dịch FT/TELLER; lãi thu/chi; các khoản thu nhập – chi phí khác.

Điểm mấu chốt về mặt mô hình: CATEG.ENTRY không có một "tài khoản khách" thực sự — đầu mục ở đây là một category code (một "tài khoản ảo"/virtual account của P&L). Vì thế các khoản này không lên sao kê khách hàng, mà được gom vào các file P&L hợp nhất (như CONSOLIDATE.PRFT.LOSS) để lên báo cáo kết quả kinh doanh.

3. RE.CONSOL.SPEC.ENTRY — bút toán đặc biệt & consolidation

RE.CONSOL.SPEC.ENTRY (Special/Consolidation Entry) dành cho những bút toán không đi qua STMT.ENTRY lẫn CATEG.ENTRY: các khoản dự phòng/dự thu-dự chi (accruals), đánh giá lại (revaluation), giao dịch ngoại bảng (contingent), và các entry đặc biệt cập nhật thẳng lên các file hợp nhất (consolidation files). Đây là "RE module" (Reporting/consolidation) — bộ máy dồn số liệu lên General Ledger.

Từ entry lên GL

Ba loại entry trên là nguyên liệu thô. T24 định nghĩa cách các entry đó được phân tích và gom nhóm để lên General Ledger thông qua cơ chế consolidation. Mỗi category / tài khoản nội bộ được ánh xạ (mapping) tới một dòng trên Chart of Account (COA) / GL line. Quá trình gom nhóm phần lớn diễn ra trong tiến trình cuối ngày — xem COB — nơi các entry trong ngày được kết chuyển và các file consolidation được cập nhật thành số dư GL cuối kỳ.

Nói ngắn gọn về đường đi kế toán:

• Tài khoản khách/nội bộ → STMT.ENTRY → consolidation → GL (Balance Sheet lines).
• P&L (phí, lãi, thu nhập-chi phí) → CATEG.ENTRY → CONSOLIDATE.PRFT.LOSS → GL (P&L lines).
• Đặc biệt / ngoại bảng / accrual → RE.CONSOL.SPEC.ENTRY → consolidation files → GL.

Sơ đồ: một lệnh FT sinh bút toán và dồn lên GL

Điểm cần đọc từ sơ đồ: một lệnh FT duy nhất có thể sinh nhiều entry (hai STMT.ENTRY cho hai vế tài khoản, cộng CATEG.ENTRY cho phí), nhưng tổng thể luôn cân bằng Nợ = Có. Đó là lý do khi đối soát, bạn không so từng dòng lẻ mà so tổng theo nhóm.

Ví dụ minh hoạ: một lệnh FT và các entry tương ứng

Giả sử khách A (10001-USD) chuyển 10.000.000 VND cho khách B (10002-VND), ngân hàng thu phí 11.000 VND. Bản ghi FT rút gọn (minh hoạ):

FUNDS.TRANSFER  id = FT2607010001         (minh hoạ)
  TRANSACTION.TYPE .... AC   (chuyển khoản nội bộ)
  DEBIT.ACCT.NO ....... 10001   DEBIT.CURRENCY  VND   DEBIT.AMOUNT  10,000,000
  CREDIT.ACCT.NO ...... 10002   CREDIT.CURRENCY VND   CREDIT.AMOUNT 10,000,000
  DEBIT.VALUE.DATE .... 20260701
  CHARGE.TYPE ......... FTCHG   CHARGE.AMOUNT  11,000   CHARGE.CATEGORY  <cat phí>
  CO.CODE ............. BNK-0001

Các entry sinh ra (minh hoạ) — chú ý cột Nợ/Có luôn cân:

                              Nợ (DR)        Có (CR)
STMT.ENTRY  acct 10001     10,000,000                  ← lên sao kê KH A
STMT.ENTRY  acct 10002                    10,000,000   ← lên sao kê KH B
STMT.ENTRY  acct 10001         11,000                  ← trích phí từ TK A
CATEG.ENTRY  cat "thu phí FT"               11,000     ← P&L: thu nhập phí
                             ----------    ----------
                    Tổng     10,011,000    10,011,000   ← Nợ = Có ✓

Ba STMT.ENTRY trên sẽ lên sao kê của hai khách; CATEG.ENTRY không lên sao kê ai mà chảy vào P&L. Khi COB chạy, các entry này được gom theo category/CO.CODE và cập nhật lên GL: dòng GL "tiền gửi khách hàng" giảm/tăng tương ứng, dòng GL "thu nhập từ phí dịch vụ" tăng 11.000.

Limits & Collateral — kiểm soát rủi ro tín dụng

Khi ngân hàng cấp tín dụng (thấu chi, cho vay, bảo lãnh), hai application đứng gác cổng rủi ro:

• LIMIT — hạn mức tín dụng cấp cho khách hàng hoặc nhóm khách hàng. LIMIT định nghĩa số tiền tối đa được phép sử dụng, kỳ hạn, và loại hạn mức (thấu chi, vay, thư tín dụng...). Khi một giao dịch (ví dụ FT làm âm tài khoản, hay giải ngân khoản vay) chạm hạn mức, T24 kiểm tra LIMIT để cho phép hoặc chặn. Mức sử dụng hạn mức (limit utilisation) là một chỉ số theo dõi rủi ro quan trọng.
• COLLATERAL — tài sản bảo đảm (bất động sản, sổ tiết kiệm, chứng khoán...) dùng để đảm bảo cho hạn mức/khoản vay. COLLATERAL liên kết với LIMIT để tính tỷ lệ bảo đảm và giá trị có thể nhận thế chấp (sau khi áp hệ số chiết khấu/haircut).

Bộ đôi LIMIT + COLLATERAL cho phép ngân hàng trả lời: "khách này được phép nợ tối đa bao nhiêu, và có gì đảm bảo phía sau?". Với Data, đây là nguồn cho báo cáo tập trung tín dụng, LTV (loan-to-value), và tính toán tài sản đảm bảo cho các khoản nợ xấu.

Multi-company / multi-book — nhiều pháp nhân trên một cài đặt

T24 hỗ trợ multi-company: một cài đặt (installation) duy nhất có thể vận hành nhiều company — mỗi company có thể là một chi nhánh, một đơn vị hạch toán, hoặc một pháp nhân riêng biệt (ví dụ ngân hàng mẹ và công ty con, hay các chi nhánh nước ngoài).

Cơ chế then chốt: mỗi bản ghi mang một CO.CODE (company code) cho biết nó thuộc company nào. Nhờ đó T24 tách sổ theo company — mỗi company có thể có sổ cái riêng, đóng sổ riêng, báo cáo riêng, và thậm chí lịch/ngày làm việc riêng. Phân quyền truy cập trong T24 cũng có thể giới hạn ở cấp company. Điều này lý giải tại sao khi truy vấn dữ liệu, CO.CODE gần như luôn là một trong những field lọc/phân nhóm đầu tiên — bỏ qua nó, bạn dễ trộn lẫn sổ của các pháp nhân khác nhau.

Use case thực tế

1. Theo dấu một khoản chuyển 10 triệu (traceability). Bộ phận đối soát nhận khiếu nại "tiền bị trừ nhưng chưa thu phí đúng". Đường đi điều tra: bắt đầu từ bản ghi FUNDS.TRANSFER (khóa giao dịch) → tìm các STMT.ENTRY có cùng tham chiếu để xác nhận hai vế nợ/có tài khoản đã đúng số tiền và đúng value date → tìm CATEG.ENTRY để kiểm tra phí đã hạch toán vào đúng category thu nhập chưa. Mỗi bước dựa trên khóa liên kết, không phải đoán. Đây là lý do STMT.ENTRY và CATEG.ENTRY được coi là mỏ vàng cho DWH và công cụ đối soát.

2. Đối soát cuối ngày (end-of-day reconciliation). Sau COB, đội tài chính so tổng các STMT.ENTRY/CATEG.ENTRY trong ngày với biến động số dư GL tương ứng. Vì hệ thống bất biến Nợ = Có, chênh lệch (nếu có) thường đến từ bút toán value-date tương lai, giao dịch đảo (reversal) chưa khớp, hoặc lệch tỷ giá — chứ không phải sổ cái "mất cân". Cân till của từng giao dịch viên (TELLER) cũng thuộc nhóm đối soát này ở cấp quầy.

Ghi nhớ

• CUSTOMER là trung tâm tham chiếu; ACCOUNT giữ số dư online và móc tới CUSTOMER/CATEGORY/CURRENCY. @ID của ACCOUNT chính là số tài khoản.
• FT và TELLER khai báo ý định nợ/có; lớp kế toán parameter-driven mới sinh entry. FT là nguồn giao dịch lớn nhất; TELLER luôn có một vế tiền mặt (till/vault).
• Ba loại entry: STMT.ENTRY (tác động tài khoản, lên sao kê), CATEG.ENTRY (P&L theo category, không lên sao kê khách), RE.CONSOL.SPEC.ENTRY (accrual/reval/ngoại bảng, dồn consolidation).
• Bất biến vàng: mọi giao dịch cân Nợ = Có; consolidation gom entry theo CATEGORY/CO.CODE và map lên Chart of Account / GL, chủ yếu trong COB.
• LIMIT + COLLATERAL kiểm soát rủi ro cấp tín dụng; CO.CODE tách sổ theo company trong môi trường multi-company.
• Góc nhìn Data: STMT.ENTRY và CATEG.ENTRY là fact tables cốt lõi; @ID account, category, value date, CO.CODE là các khóa phân tích và lọc bắt buộc.

Đọc tiếp: Arrangement Architecture — sản phẩm vay/gửi · Mô hình dữ liệu T24 · COB — kết chuyển GL cuối ngày