Hiểu về các Định dạng Sao kê Ngân hàng: Hướng dẫn Kỹ thuật

Một tệp PDF sao kê ngân hàng trông có vẻ đơn giản: ngày tháng, mô tả, số tiền, số dư trong các cột gọn gàng. Nhưng đằng sau vẻ ngoài đó là một định dạng tài liệu (PDF) chưa bao giờ được thiết kế để lưu trữ dữ liệu có cấu trúc - và một quy trình chuyển đổi đòi hỏi sự hiểu biết cả về định dạng đầu vào lẫn nhiều định dạng đầu ra có sẵn.

Hướng dẫn này bao gồm 12 phần xuất hiện trên mọi sao kê ngân hàng (bất kể ngân hàng nào), thực tế kỹ thuật của các tệp PDF sao kê ngân hàng, các biến thể bố cục giữa các ngân hàng, mọi định dạng đầu ra bạn sẽ gặp (Excel, CSV, QBO, OFX, QFX, QIF, JSON), sự khác biệt về định dạng quốc tế và các tiêu chuẩn ngành điều chỉnh trao đổi dữ liệu tài chính.

Cấu trúc của một Sao kê Ngân hàng

Mọi sao kê ngân hàng - Chase, Bank of America, Wells Fargo, HSBC, Deutsche Bank, v.v. - đều được xây dựng từ 12 phần giống nhau. Nhãn có thể thay đổi ("Khoản trừ" so với "Rút tiền"), cách sắp xếp cột có thể khác nhau, nhưng cấu trúc cơ bản là nhất quán. Một khi bạn có thể xác định các phần này, mọi sao kê sẽ trở nên quen thuộc.

Muốn sử dụng infographic này trên blog của bạn? Sao chép mã nhúng này:

Để tìm hiểu sâu về từng ngân hàng, bao gồm cách mỗi ngân hàng lớn sắp xếp 12 phần này, hãy xem:

• Giải thích sao kê ngân hàng Chase
• Giải thích sao kê ngân hàng Bank of America
• Giải thích sao kê ngân hàng Wells Fargo
• Giải thích sao kê ngân hàng Citi
• Giải thích sao kê ngân hàng Capital One

Tại sao PDF Không phải là Định dạng Dữ liệu

PDF là viết tắt của Định dạng Tài liệu Di động (Portable Document Format), được chuẩn hóa là ISO 32000 (phiên bản 2.0 trở thành ISO 32000-2:2020). Nó được thiết kế cho một mục đích: làm cho tài liệu trông giống hệt nhau trên mọi màn hình và máy in. Điều đó tuyệt vời cho độ trung thực hình ảnh - và tồi tệ cho việc trích xuất dữ liệu.

Thực sự Bên trong một Tệp PDF Sao kê Ngân hàng có gì

Bên trong mỗi trang PDF là một luồng nội dung (content stream) - một chuỗi các toán tử vẽ được viết bằng ngôn ngữ giống PostScript. Văn bản được hiển thị bằng các toán tử cụ thể:

• BT / ET - Bắt đầu Văn bản / Kết thúc Văn bản: ranh giới của một đối tượng văn bản
• Tf - Đặt phông chữ và kích thước
• Td / Tm - Di chuyển vị trí văn bản hoặc đặt ma trận biến đổi văn bản đầy đủ
• Tj - Hiển thị một chuỗi văn bản
• TJ - Hiển thị văn bản với định vị từng ký tự riêng lẻ (điều chỉnh khoảng cách chữ)

Điểm mấu chốt: không có khái niệm "bảng", "hàng" hay "cột" trong đặc tả PDF. Những gì trông giống như một bảng giao dịch được định dạng gọn gàng thực chất là hàng chục đoạn văn bản được đặt ở các tọa độ x,y cụ thể trên trang. Công cụ trích xuất phải:

1. Phân tích các toán tử luồng nội dung
2. Giải mã các bảng mã phông chữ để ánh xạ các chỉ số ký tự đến ký tự Unicode
3. Sử dụng ma trận văn bản (Tm/Td) để xác định vị trí x,y của mọi ký tự
4. Tái tạo các từ, dòng và cột từ các tọa độ đó

Một cột có vẻ căn chỉnh hoàn hảo có thể ở x=72.0 trên một dòng và x=72.5 trên dòng tiếp theo. Thuật toán trích xuất phải xác định ranh giới cột với dung sai cho các biến thể dưới pixel này.

PDF được Gắn thẻ (Tagged) so với PDF không được Gắn thẻ

PDF được gắn thẻ bao gồm một cây cấu trúc logic ẩn (tương tự như thẻ HTML) đánh dấu nội dung là tiêu đề, đoạn văn, bảng, hàng bảng và ô bảng. Điều này làm cho việc trích xuất dễ dàng hơn đáng kể.

PDF không được gắn thẻ không có siêu dữ liệu cấu trúc - công cụ trích xuất chỉ nhận dữ liệu vị trí thô và phải tự suy luận mọi thứ.

Hầu hết các tệp PDF sao kê do ngân hàng tạo ra đều không được gắn thẻ. Các ngân hàng tạo sao kê bằng hệ thống xử lý hàng loạt (Oracle BI Publisher, SAP Crystal Reports hoặc quy trình in-to-PDF tùy chỉnh). Các quy định về khả năng truy cập (ADA/WCAG) đang thúc đẩy các ngân hàng sử dụng PDF được gắn thẻ, nhưng việc áp dụng còn chậm. Các bản tải xuống tiêu chuẩn từ hầu hết các ngân hàng lớn vẫn không được gắn thẻ.

Biến thể Bố cục Sao kê Ngân hàng

Không có tiêu chuẩn ngành nào về cách các ngân hàng định dạng sao kê PDF của họ. Năm thông tin giống nhau - ngày, mô tả, ghi nợ, ghi có, số dư - được sắp xếp khác nhau bởi mỗi ngân hàng.

Một Cột Số tiền (Có dấu)

Ngày Mô tả Số tiền Số dư
15/01/26 TRẢ LƯƠNG TRỰC TIẾP +3.500,00 5.200,00
16/01/26 MUA HÀNG TẠI CỬA HÀNG -87,50 5.112,50

Các khoản ghi nợ là số âm, các khoản ghi có là số dương (hoặc ngược lại). Phổ biến với các ngân hàng nhỏ hơn, liên minh tín dụng và ngân hàng kỹ thuật số. Dễ phân tích hơn vì chỉ có một cột số tiền để trích xuất.

Cột Ghi nợ/Ghi có Riêng biệt

Ngày Mô tả Rút tiền Nộp tiền Số dư
15/01/26 TRẢ LƯƠNG TRỰC TIẾP 3.500,00 5.200,00
16/01/26 MUA HÀNG TẠI CỬA HÀNG 87,50 5.112,50

Được sử dụng bởi Chase, Bank of America và nhiều ngân hàng truyền thống. Công cụ trích xuất phải xác định cột nào chứa số tiền và xác định dấu tương ứng.

Nhóm theo Loại Giao dịch

Các tài khoản doanh nghiệp và thương mại thường nhóm các giao dịch:

CÁC KHOẢN NỘP VÀ CÁC KHOẢN CÓ KHÁC 15/01  Chuyển khoản đến REF#12345 10.000,00 18/01  Nộp séc #4567 2.500,00 Tổng tiền nộp 12.500,00
 
CÁC KHOẢN THANH TOÁN BẰNG SÉC 16/01  Séc #1234 850,00 17/01  Séc #1235 1.200,00 Tổng séc đã thanh toán 2.050,00
 
GIAO DỊCH ĐIỆN TỬ 19/01  Thanh toán ACH - Công ty Bán hàng 3.200,00 20/01  Chuyển khoản trực tuyến sang Tiết kiệm 1.000,00 Tổng giao dịch điện tử 4.200,00

Các tiêu đề phần xác định xem giao dịch là ghi nợ hay ghi có. Các dòng tóm tắt ("Tổng tiền nộp") phải được xác định và loại trừ khỏi dữ liệu giao dịch.

Đặc điểm Riêng của Ngân hàng

• Chase - Cột ghi nợ/ghi có riêng biệt; nhóm theo "CÁC KHOẢN NỘP VÀ CỘNG THÊM" và "THANH TOÁN ĐIỆN TỬ" và "PHÍ"; mô tả nhiều dòng phổ biến cho chi tiết người bán
• Bank of America - Cột rút tiền/nộp tiền riêng biệt; bao gồm phần "Tóm tắt Số dư Hàng ngày" ở cuối; tiêu đề phong phú với số tài khoản, kỳ sao kê, số định tuyến
• Wells Fargo - Cột riêng biệt; bao gồm phần "TÓM TẮT SỐ DƯ HÀNG NGÀY"; gọi bản tải xuống CSV của họ là "Comma Delimited"
• Capital One - Bố cục một số tiền rõ ràng cho thẻ tiêu dùng; thông tin tiêu đề tối thiểu
• Citi - Thường bao gồm chi tiết giao dịch quốc tế với số tiền gốc và tỷ giá chuyển đổi trên các dòng riêng biệt

Biến thể Sắp xếp Cột

Ngoài câu hỏi ghi nợ/ghi có, thứ tự cột không được chuẩn hóa:

• Thứ tự cột: Ngày-Mô tả-Số tiền-Số dư so với Ngày-Số tiền-Mô tả-Số dư
• Số séc: Có trong tài khoản doanh nghiệp, vắng mặt trong tài khoản cá nhân
• Số tham chiếu: Phổ biến trong sao kê doanh nghiệp, hiếm khi có trong tài khoản cá nhân
• Số dư lũy kế: Theo từng giao dịch (phổ biến nhất) so với tổng số dư hàng ngày so với hoàn toàn vắng mặt

PDF Kỹ thuật số so với PDF Quét

Yếu tố quan trọng nhất ảnh hưởng đến độ chính xác của chuyển đổi là liệu tệp PDF của bạn là kỹ thuật số hay được quét.

PDF Kỹ thuật số (Gốc)

Được tạo theo chương trình bởi hệ thống ngân hàng của bạn khi bạn tải xuống sao kê. Văn bản được lưu trữ dưới dạng các toán tử luồng nội dung với mã hóa phông chữ.

• Độ chính xác: 99%+ cho việc trích xuất văn bản - không có lỗi nhận dạng
• Tốc độ: mili giây mỗi trang
• Quyền riêng tư: Có thể được xử lý hoàn toàn trong trình duyệt của bạn - tệp không bao giờ rời khỏi thiết bị của bạn
• Kích thước tệp: Thường từ 50KB–500KB mỗi trang
• Cách nhận biết: Bạn có thể chọn và làm nổi bật từng từ

PDF Quét

Hình ảnh của các sao kê giấy - được tạo bằng cách quét hoặc chụp ảnh một tài liệu vật lý. Nội dung được lưu trữ dưới dạng hình ảnh raster (JPEG, JPEG2000, CCITT hoặc nén Flate).

• Độ chính xác: 95–99% với OCR chuyên nghiệp; 65–70% với OCR chung
• Tốc độ: giây mỗi trang (yêu cầu xử lý hình ảnh)
• Quyền riêng tư: Thường yêu cầu xử lý phía máy chủ (tệp phải được tải lên để OCR)
• Kích thước tệp: 200KB–2MB+ mỗi trang
• Cách nhận biết: Bạn không thể chọn bất kỳ văn bản nào; phóng to 400% cho thấy hình ảnh bị pixel hóa

Tại sao Độ chính xác Quét lại Quan trọng hơn đối với Dữ liệu Tài chính

Tỷ lệ chính xác ký tự 97% nghe có vẻ tuyệt vời cho đến khi bạn áp dụng nó cho dữ liệu tài chính. Trên một sao kê có 1.000 ký tự số tiền, đó là 30 ký tự bị đọc sai. Một chữ số bị đọc sai duy nhất sẽ thay đổi số tiền giao dịch: "1.234,56 $ " trở thành "1.234,86 $ " hoặc "7.234,56 $ ". OCR nâng cao đạt độ chính xác gần 99%, nhưng các lỗi còn lại chủ yếu rơi vào các ký tự trông giống nhau: 0/O, 1/l/I, 5/S, 8/B, 6/G, và quan trọng là dấu phẩy/dấu chấm. Luôn ưu tiên tải xuống kỹ thuật số. Tải xuống sao kê từ trang web của ngân hàng thay vì quét giấy. Điều này loại bỏ hoàn toàn lỗi OCR.

Định dạng Đầu ra: Tìm hiểu Sâu

Khi bạn chuyển đổi sao kê ngân hàng, bạn chọn một định dạng đầu ra. Mỗi định dạng có những điểm mạnh, hạn chế và trường hợp sử dụng lý tưởng riêng.

Excel (.xlsx)

Tiêu chuẩn: Office Open XML (OOXML), được chuẩn hóa là ECMA-376 và ISO/IEC 29500.

Nó là gì: Một tệp .xlsx thực chất là một kho lưu trữ ZIP chứa các tệp XML - cấu trúc sổ làm việc, dữ liệu ô, kiểu dáng và chuỗi chia sẻ. Đây là lý do tại sao nó có thể lưu trữ các loại dữ liệu (ngày dưới dạng ngày, số dưới dạng số), định dạng, công thức và nhiều trang.

Tại sao nó phổ biến cho sao kê ngân hàng:

• Ngày tháng vẫn là ngày tháng (có thể sắp xếp, lọc)
• Số vẫn là số (có thể tính tổng, định dạng)
• Công thức để đối chiếu (SUM, VLOOKUP)
• Bảng tổng hợp để phân loại chi tiêu
• Định dạng có điều kiện để làm nổi bật sự khác biệt
• Chia sẻ với khách hàng cần bảng tính có thể đọc được

Hạn chế:

• Tối đa 1.048.576 hàng (hiếm khi liên quan đến sao kê ngân hàng)
• Không thể nhập trực tiếp vào hầu hết các phần mềm kế toán (sử dụng QBO/OFX thay thế)
• Yêu cầu Excel, Google Sheets hoặc LibreOffice Calc để mở

Tốt nhất cho: Xem xét thủ công, phân tích tùy chỉnh, đối chiếu, lưu trữ, báo cáo cho khách hàng.

CSV (Comma-Separated Values - Giá trị Phân tách bằng Dấu phẩy)

Tiêu chuẩn: RFC 4180 (2005) - "Định dạng Chung và Loại MIME cho Giá trị Phân tách bằng Dấu phẩy."

Quy tắc cốt lõi:

• Bản ghi được phân tách bằng CRLF (ký tự xuống dòng + xuống dòng)
• Trường được phân tách bằng dấu phẩy
• Các trường chứa dấu phẩy, dấu ngoặc kép hoặc ngắt dòng phải được đặt trong dấu ngoặc kép
• Dấu ngoặc kép bên trong trường được thoát bằng cách nhân đôi chúng

Biến thể dấu phân cách trong thực tế:

• Dấu phẩy (,) - Tiêu chuẩn, được sử dụng ở Mỹ/Anh
• Dấu chấm phẩy (;) - Được sử dụng ở các quốc gia mà dấu phẩy là dấu phân cách thập phân (Pháp, Đức, Ý, Tây Ban Nha, Brazil)
• Tab (\t) - Định dạng TSV, tránh xung đột dấu phân cách

Vấn đề mã hóa:

• UTF-8 được khuyến nghị để tương tác
• UTF-8 BOM (Byte Order Mark): Không bắt buộc theo tiêu chuẩn, nhưng Excel trên Windows yêu cầu nó để hiển thị chính xác các ký tự không phải ASCII (chữ có dấu, ký hiệu tiền tệ). Nếu không có BOM, Excel có thể diễn giải UTF-8 thành Windows-1252, làm hỏng ký tự.
• Excel sử dụng dấu chấm phẩy thay vì dấu phẩy làm dấu phân cách trường trong các vùng địa lý Châu Âu

Hạn chế:

• Không có kiểu dữ liệu - mọi thứ đều là văn bản (số có số 0 ở đầu bị hỏng, số tài khoản dài trở thành ký hiệu khoa học)
• Không hỗ trợ nhiều trang
• Không có định dạng hoặc công thức
• Không có siêu dữ liệu (không có thông tin tài khoản, không có ID phát hiện trùng lặp)

Tốt nhất cho: Khả năng tương thích tối đa - hầu hết mọi chương trình kế toán, cơ sở dữ liệu và bảng tính đều có thể nhập CSV. Lựa chọn dự phòng phổ quát khi QBO/OFX không có sẵn.

QBO (QuickBooks Web Connect)

Nó là gì: Định dạng nhập cho QuickBooks (cả phiên bản Desktop và Online). Tệp QBO dựa trên đặc tả OFX với các phần mở rộng dành riêng cho QuickBooks.

Làm rõ quan trọng: ".QBO" KHÔNG có nghĩa là "QuickBooks Online" - nó là viết tắt của định dạng QuickBooks Web Connect và hoạt động với cả QuickBooks Desktop và QuickBooks Online.

Các trường bắt buộc cho mỗi giao dịch:

• TRNTYPE - Loại giao dịch (DEBIT, CREDIT, CHECK, DEP, DIRECTDEP, DIRECTDEBIT, ATM, POS, XFER, PAYMENT, FEE, SRVCHG, INT, OTHER)
• DTPOSTED - Ngày theo định dạng YYYYMMDD
• TRNAMT - Số tiền (âm cho ghi nợ)
• FITID - Mã giao dịch của Tổ chức Tài chính
• NAME - Người nhận/mô tả

Tại sao FITID lại quan trọng: QuickBooks theo dõi mọi FITID từng được nhập cho mỗi tài khoản. Nếu một giao dịch có cùng FITID được nhập lại, QuickBooks sẽ bỏ qua nó một cách lặng lẽ - ngăn chặn các mục trùng lặp khi người dùng nhập lại các kỳ sao kê chồng chéo. Tính năng phát hiện trùng lặp tự động này là lợi thế lớn nhất của QBO so với CSV.

Dữ liệu bổ sung: QBO cũng mang ID tài khoản, ID ngân hàng (số định tuyến), tiền tệ, số séc, ghi nhớ và số dư cuối kỳ - bộ dữ liệu phong phú nhất trong bất kỳ định dạng nhập nào cho QuickBooks.

Tốt nhất cho: Người dùng QuickBooks (Desktop và Online). Cung cấp trải nghiệm nhập phong phú nhất với tính năng phát hiện trùng lặp tự động và phân loại loại giao dịch.

OFX (Open Financial Exchange - Trao đổi Tài chính Mở)

Lịch sử: Được tạo bởi Microsoft, Intuit và CheckFree. Phiên bản 1.0 phát hành tháng 2 năm 1997.

Tiến hóa phiên bản:

• OFX 1.0–1.6 (1997–1999): Cú pháp dựa trên SGML (không yêu cầu thẻ đóng)
• OFX 2.0+ (2000–nay): Dựa trên XML (thẻ đóng đúng, XML hợp lệ)

Nhiều ngân hàng vẫn sản xuất OFX 1.x (SGML) để có khả năng tương thích tối đa.

Quản trị hiện tại: Năm 2019, tập đoàn OFX đã hợp nhất vào tập đoàn Financial Data Exchange (FDX), hiện đang quản lý đặc tả. FDX có hơn 200 tổ chức thành viên và 76 triệu tài khoản người tiêu dùng.

Tại sao OFX là tiêu chuẩn phổ quát: OFX là định dạng giống nhau được sử dụng khi bạn kết nối trực tiếp tài khoản ngân hàng của mình với phần mềm kế toán thông qua các luồng ngân hàng - định dạng giống nhau hoạt động cho các tệp nhập.

Tốt nhất cho người dùng Xero: Xero tự động nhập tệp OFX mà không yêu cầu ánh xạ cột thủ công. Tải lên tệp và các giao dịch sẽ xuất hiện ngay lập tức với ngày, số tiền và mô tả chính xác. Cũng hoạt động với Wave, Sage, FreshBooks và hầu hết các phần mềm kế toán.

QFX (Quicken Financial Exchange)

Nó là gì: Biến thể độc quyền của OFX của Intuit, chỉ được sử dụng với Quicken. Tệp QFX là một tệp OFX tiêu chuẩn với các trường độc quyền bổ sung.

Trường độc quyền chính: INTU.BID - Mã định danh Ngân hàng Quicken. ID số này ánh xạ tới một ngân hàng trong cơ sở dữ liệu nội bộ của Quicken. Nếu không có nó, Quicken sẽ từ chối nhập tệp.

Khác biệt so với OFX tiêu chuẩn:

• Yêu cầu INTU.BID trong tiêu đề
• Có thể bao gồm các trường khác có tiền tố INTU.*
• Các tổ chức tài chính trả phí cấp phép cho Intuit để cung cấp bản tải xuống QFX
• Quicken sẽ không nhập các tệp OFX tiêu chuẩn nếu không có trường INTU.BID

Tốt nhất cho: Người dùng phần mềm tài chính cá nhân Quicken. Định dạng bắt buộc - không có lựa chọn thay thế nào hoạt động.

QIF (Quicken Interchange Format - Định dạng Trao đổi Quicken)

Nó là gì: Một định dạng văn bản thuần túy cũ được Intuit phát triển ban đầu cho Quicken. Các cặp thẻ-giá trị, mỗi cặp trên một dòng, với các thẻ một ký tự: D cho ngày, T cho số tiền, P cho người nhận, L cho danh mục, M cho ghi nhớ, N cho số séc, ^ cho kết thúc bản ghi.

Tại sao nó bị thay thế: QIF thiếu cơ chế phát hiện trùng lặp (không có tương đương FITID), không có trường nhận dạng tài khoản, không có thông tin định tuyến ngân hàng, không có dữ liệu số dư và định dạng ngày tháng không nhất quán giữa các lần triển khai.

Vẫn còn liên quan: Một số phần mềm kế toán (Xero, Sage, GnuCash) vẫn chấp nhận nhập QIF. Hữu ích cho việc di chuyển hệ thống cũ.

JSON (JavaScript Object Notation)

Tình trạng hiện tại: JSON chưa phải là tiêu chuẩn cho các tệp sao kê ngân hàng, nhưng ngày càng được sử dụng trong:

• API Ngân hàng Mở (Tiêu chuẩn Ngân hàng Mở Vương quốc Anh, Nhóm Berlin PSD2)
• API FDX (Financial Data Exchange - kế nhiệm của OFX, hơn 200 tổ chức thành viên)
• Plaid, Yodlee, MX và các API tổng hợp dữ liệu khác
• Luồng công việc phát triển và tự động hóa

Sự chấp nhận ngày càng tăng: Các quy định về Ngân hàng Mở (PSD2 ở Châu Âu, Mục 1033 của CFPB ở Mỹ) đang thúc đẩy việc áp dụng API JSON. API FDX sử dụng JSON/REST với OAuth 2.0, đại diện cho hướng tương lai của trao đổi dữ liệu tài chính.

Tốt nhất cho: Các nhà phát triển xây dựng các luồng công việc tự động, tích hợp fintech, bảng điều khiển tùy chỉnh và tích hợp API Ngân hàng Mở.

So sánh Định dạng Nhanh

Khả năng Tương thích Phần mềm Kế toán

Phần mềm kế toán của bạn chấp nhận định dạng nào?

Quy tắc chung: Sử dụng QBO cho QuickBooks, QFX cho Quicken, OFX cho các phần mềm khác, và CSV làm phương án dự phòng phổ quát.

Khác biệt Định dạng Quốc tế

Nếu bạn làm việc với các sao kê ngân hàng quốc tế, bạn sẽ gặp các khác biệt về định dạng làm các công cụ chuyển đổi gặp khó khăn.

Định dạng Ngày tháng

Vấn đề mơ hồ: "03/04/2026" là ngày 3 tháng 4 ở Mỹ nhưng là ngày 4 tháng 3 ở Châu Âu. Khi tất cả các ngày trong sao kê có giá trị ngày dưới 12, không có cách nào để xác định định dạng chính xác mà không biết quốc gia xuất xứ. Các công cụ chuyển đổi phải quét tất cả các ngày trong sao kê, tìm kiếm các giá trị lớn hơn 12 để xác định định dạng.

Định dạng Số

"10.000,45" từ một ngân hàng Châu Âu có nghĩa là mười nghìn bốn mươi lăm xu - không phải mười phẩy không không không bốn năm. Làm sai điều này sẽ gây ra lỗi với độ lớn gấp 10.000 lần.

Vị trí Ký hiệu Tiền tệ

• Mỹ/Anh: Ký hiệu trước số tiền: $1.234,56 / £1.234,56
• Pháp, Đức, Tây Ban Nha: Ký hiệu sau số tiền: 1.234,56 €
• Ireland, Hà Lan: Ký hiệu trước: €1.234,56
• Nhật Bản: Ký hiệu trước: ¥123.456

Mã hóa Ký tự

• UTF-8 - Tiêu chuẩn phổ quát, hỗ trợ tất cả các bảng chữ cái
• GBK/GB2312 - Tiếng Trung giản thể (được sử dụng bởi các ngân hàng Trung Quốc)
• Shift_JIS - Tiếng Nhật (được sử dụng bởi các ngân hàng Nhật Bản)
• Big5 - Tiếng Trung phồn thể (Đài Loan, Hồng Kông)
• EUC-KR - Tiếng Hàn
• ISO 8859-1 - Tây Âu
• Windows-1252 - Tây Âu (cũ)
• Windows-1256 - Tiếng Ả Rập

Mở một sao kê ngân hàng Trung Quốc hoặc Nhật Bản trên hệ thống Mỹ mà không có mã hóa đúng sẽ tạo ra các ký tự bị hỏng. PDFSub xử lý hơn 130 ngôn ngữ với khả năng tự động phát hiện định dạng ngày, định dạng số và mã hóa ký tự - bao gồm cả tiếng Ả Rập và tiếng Do Thái từ phải sang trái, ký tự CJK và tất cả các bộ ký tự Châu Âu.

Các Yếu tố Phổ biến trên Sao kê Ngân hàng

Ngày Giao dịch so với Ngày Ghi sổ so với Ngày Giá trị

Sao kê ngân hàng có thể bao gồm nhiều ngày cho một giao dịch duy nhất:

• Ngày giao dịch - Thời điểm mua hoặc chuyển khoản thực sự xảy ra
• Ngày ghi sổ - Thời điểm ngân hàng xử lý và ghi nhận nó (thường là 1–3 ngày làm việc sau đó đối với các giao dịch mua bằng thẻ tín dụng)
• Ngày giá trị - Thời điểm tiền thực sự có sẵn (ảnh hưởng đến tính lãi, phổ biến trong ngân hàng quốc tế)

Hầu hết các sao kê người tiêu dùng chỉ hiển thị ngày ghi sổ. Sao kê doanh nghiệp thường bao gồm cả ngày giao dịch và ngày ghi sổ.

Biểu diễn Ghi nợ/Ghi có

Các ngân hàng biểu diễn ghi nợ và ghi có khác nhau:

• Số tiền có dấu: -87,50 cho ghi nợ, +3.500,00 cho ghi có
• Cột riêng biệt: "Rút tiền" và "Nộp tiền"
• Viết tắt: "DR" cho ghi nợ, "CR" cho ghi có (phổ biến ở Anh/Khối thịnh vượng chung)
• Dấu ngoặc đơn: (87,50) cho ghi nợ (quy ước kế toán)

Số dư Lũy kế

• Số dư theo từng giao dịch - Cập nhật sau mỗi giao dịch (phổ biến nhất trong sao kê người tiêu dùng Hoa Kỳ)
• Chỉ số dư hàng ngày - Số dư hiển thị vào cuối mỗi ngày (phổ biến trong sao kê doanh nghiệp)
• Không có số dư lũy kế - Chỉ có số dư đầu kỳ và cuối kỳ (một số sao kê quốc tế)

Số dư lũy kế có giá trị để xác minh: bạn có thể kiểm tra xem mỗi giao dịch có di chuyển số dư từ dòng này sang dòng tiếp theo một cách chính xác hay không.

Thông tin Tiêu đề Tiêu chuẩn

Hầu hết các sao kê ngân hàng bao gồm: tên chủ tài khoản, số tài khoản (thường được che một phần), kỳ sao kê, số dư đầu kỳ và cuối kỳ, tổng tiền nộp và rút, và mã định tuyến/mã sắp xếp/SWIFT BIC của ngân hàng.

Bảo vệ bằng Mật khẩu

Cách Ngân hàng Mã hóa PDF

Các ngân hàng thường sử dụng mã hóa AES-128 hoặc AES-256. Tồn tại hai chế độ bảo vệ:

• Mật khẩu người dùng (mật khẩu mở): Bắt buộc để mở tệp
• Mật khẩu chủ sở hữu (mật khẩu quyền): PDF mở nhưng có thể bị hạn chế chỉnh sửa/sao chép

Mẫu Mật khẩu Phổ biến

Các mẫu phổ biến khác bao gồm 4 chữ số cuối của số tài khoản, ID khách hàng hoặc số thành viên. Các ngân hàng thường thông báo mẫu mật khẩu khi bạn lần đầu kích hoạt sao kê điện tử.

Thách thức với Sao kê Nhiều Trang

Các sao kê dài (tài khoản doanh nghiệp với hàng trăm giao dịch) tạo ra một số thách thức trích xuất:

Giao dịch bị Chia tách

Mô tả giao dịch có thể bắt đầu ở cuối một trang và tiếp tục ở đầu trang tiếp theo. Bộ chuyển đổi phải phát hiện các dòng tiếp nối và hợp nhất chúng thành một giao dịch duy nhất.

Tiêu đề và Chân trang Lặp lại

Hầu hết các ngân hàng lặp lại tiêu đề cột trên mỗi trang, cộng với số trang, tuyên bố pháp lý và văn bản quảng cáo. Chúng phải được xác định và loại trừ khỏi dữ liệu giao dịch.

Dòng Tiếp nối

Nhiều giao dịch có mô tả nhiều dòng:

15/01  GHI NỢ ĐIỆN TỬ ACH CÔNG TY BÁN HÀNG 3.200,00 $  2.000,00 $ REF#123456789 HÓA ĐƠN 2026-001 CÔNG TY BÁN HÀNG PHÒNG KẾ TOÁN PHẢI TRẢ

Dòng 2 và 3 là các dòng tiếp nối thuộc về giao dịch ở dòng 1. Chúng thường thiếu ngày tháng và số tiền, xuất hiện thụt lề ở cùng tọa độ x với cột mô tả.

Chuyển số dư

Một số ngân hàng bao gồm các dòng "Số dư chuyển tiếp" hoặc "Số dư chuyển trước" ở đầu các trang tiếp nối. Chúng mang tính thông tin, không phải giao dịch, và phải được loại trừ khỏi dữ liệu đã trích xuất.

Viết tắt Giao dịch Phổ biến

Sao kê ngân hàng sử dụng các từ viết tắt khác nhau tùy theo tổ chức:

Tiêu chuẩn Ngành bạn Nên Biết

Các định dạng này được sử dụng trong ngân hàng doanh nghiệp và quản lý kho quỹ. Bạn hiếm khi gặp chúng trực tiếp, nhưng hiểu biết về chúng sẽ giải thích tại sao sao kê ngân hàng hoạt động như vậy.

BAI2 (Bank Administration Institute - Viện Quản lý Ngân hàng)

Được sử dụng cho quản lý tiền mặt tự động và đối chiếu ngân hàng trong các hệ thống ERP (SAP, Oracle). Một định dạng ASCII có độ rộng cố định với các mã loại giao dịch (ví dụ: 165 = tín dụng ACH được ủy quyền trước, 455 = ghi nợ ACH, 495 = chuyển khoản điện tử đi). Ban đầu được phát hành năm 1987, hiện được ASC X9 duy trì.

SWIFT MT940 / MT940

Sao kê ngân hàng cuối ngày (MT940) và trong ngày (MT942) được các ngân hàng trên toàn thế giới sử dụng cho khách hàng doanh nghiệp và bộ phận kho quỹ. SWIFT xử lý khoảng 45 triệu tin nhắn mỗi ngày. Định dạng dựa trên thẻ với các định danh trường phân tách bằng dấu hai chấm.

ISO 20022 (camt.053)

Sự thay thế dựa trên XML hiện đại cho MT940. Là một phần của tiêu chuẩn nhắn tin tài chính phổ quát ISO 20022. Dữ liệu phong phú hơn MT940, không giới hạn độ dài trường, XML có thể phân tích bằng máy với xác thực XSD. SWIFT đang chuyển đổi từ tin nhắn MT sang ISO 20022. SEPA (Khu vực Thanh toán Euro Thống nhất) yêu cầu định dạng camt cho các khoản thanh toán Châu Âu.

NACHA ACH

Định dạng tệp cho các giao dịch Automated Clearing House ở Hoa Kỳ. ASCII có độ rộng cố định, chính xác 94 ký tự mỗi dòng. ACH xử lý khoảng 30 tỷ giao dịch mỗi năm ở Hoa Kỳ. Khi sao kê ngân hàng của bạn hiển thị "ACH CREDIT" hoặc "ACH DEBIT", giao dịch cơ bản đã được truyền dưới dạng NACHA giữa các ngân hàng.

Chọn Định dạng Phù hợp cho Quy trình Làm việc của Bạn

Hướng dẫn Quyết định

Sử dụng QBO nếu: Bạn sử dụng QuickBooks (Desktop hoặc Online). Bạn nhận được phân loại loại giao dịch, phát hiện trùng lặp qua FITID và siêu dữ liệu nhập phong phú nhất.

Sử dụng OFX nếu: Bạn sử dụng Xero, Sage, Wave hoặc các phần mềm tương thích OFX khác. Xero tự động ánh xạ các trường mà không cần cấu hình cột thủ công.

Sử dụng QFX nếu: Bạn sử dụng Quicken. Đây là định dạng duy nhất Quicken chấp nhận.

Sử dụng Excel nếu: Bạn cần xem xét, phân tích hoặc thao tác dữ liệu trước khi nhập. Tạo bảng tổng hợp, chạy công thức hoặc chuẩn bị báo cáo.

Sử dụng CSV nếu: Phần mềm của bạn không có trong danh sách trên, hoặc bạn cần khả năng tương thích tối đa trên các hệ thống. Hãy chuẩn bị để ánh xạ các cột thủ công.

Sử dụng JSON nếu: Bạn đang xây dựng các quy trình làm việc tự động, tích hợp API hoặc hệ thống báo cáo tùy chỉnh.

Mẹo chuyên nghiệp

• Luôn sử dụng QBO/OFX thay vì CSV khi phần mềm của bạn hỗ trợ - chỉ riêng tính năng phát hiện trùng lặp đã giúp tiết kiệm hàng giờ dọn dẹp
• Giữ lại tệp PDF gốc cùng với tệp đã chuyển đổi của bạn - đó là dấu vết kiểm toán và tài liệu nguồn của bạn
• Xác minh sau mỗi lần nhập - kiểm tra nhanh số dư đầu kỳ/cuối kỳ và một vài giao dịch ngẫu nhiên
• Khớp định dạng với phần mềm - sử dụng định dạng gốc cho nền tảng kế toán của bạn sẽ tránh được việc ánh xạ cột thủ công và kích hoạt các tính năng tự động

Dùng thử Miễn phí

Sẵn sàng chuyển đổi sao kê đầu tiên của bạn? Tải lên PDF ngay bây giờ - PDFSub chuyển đổi sang Excel, CSV, QBO, OFX, QFX và JSON. Các sao kê kỹ thuật số được xử lý hoàn toàn trong trình duyệt của bạn để đảm bảo quyền riêng tư tối đa. Bắt đầu dùng thử miễn phí 7 ngày với quyền truy cập đầy đủ vào tất cả các định dạng.