Memahami Format Laporan Bank: Panduan Teknis

Laporan bank dalam format PDF terlihat sederhana: tanggal, deskripsi, jumlah, saldo dalam kolom rapi. Namun, di balik tampilan itu terdapat format dokumen (PDF) yang tidak pernah dirancang untuk menyimpan data terstruktur—dan proses konversi yang memerlukan pemahaman baik tentang format masukan maupun berbagai format keluaran yang tersedia.

Panduan ini mencakup 12 bagian yang muncul di setiap laporan bank (terlepas dari banknya), realitas teknis PDF laporan bank, variasi tata letak antar bank, setiap format keluaran yang akan Anda temui (Excel, CSV, QBO, OFX, QFX, QIF, JSON), perbedaan format internasional, dan standar industri yang mengatur pertukaran data keuangan.

Anatomi Laporan Bank

Setiap laporan bank—Chase, Bank of America, Wells Fargo, HSBC, Deutsche Bank, apa pun namanya—dibangun dari 12 bagian yang sama. Labelnya berubah ("Pengurangan" vs "Penarikan"), susunan kolom bervariasi, tetapi struktur dasarnya konsisten. Begitu Anda dapat mengidentifikasi bagian-bagian ini, setiap laporan akan terlihat familiar.

Ingin menggunakan infografis ini di blog Anda? Salin kode semat ini:

Untuk analisis mendalam spesifik bank yang mencakup persis bagaimana setiap bank besar menyusun 12 bagian ini, lihat:

• Penjelasan laporan bank Chase
• Penjelasan laporan bank Bank of America
• Penjelasan laporan bank Wells Fargo
• Penjelasan laporan bank Citi
• Penjelasan laporan bank Capital One

Mengapa PDF Bukan Format Data

PDF adalah singkatan dari Portable Document Format, yang distandardisasi sebagai ISO 32000 (versi 2.0 menjadi ISO 32000-2:2020). PDF dirancang untuk satu tujuan: membuat dokumen terlihat identik di setiap layar dan printer. Ini bagus untuk kesetiaan visual—dan buruk untuk ekstraksi data.

Apa yang Sebenarnya Ada di Dalam PDF Laporan Bank

Di dalam setiap halaman PDF terdapat content stream—urutan operator gambar yang ditulis dalam bahasa mirip PostScript. Teks dirender menggunakan operator spesifik:

• BT / ET - Mulai Teks / Akhiri Teks: batas objek teks
• Tf - Atur font dan ukuran
• Td / Tm - Pindahkan posisi teks atau atur matriks transformasi teks lengkap
• Tj - Tampilkan string teks
• TJ - Tampilkan teks dengan pemosisian glif individual (penyesuaian kerning)

Wawasan penting: tidak ada konsep "tabel," "baris," atau "kolom" dalam spesifikasi PDF. Apa yang terlihat seperti tabel transaksi yang diformat dengan rapi sebenarnya adalah puluhan fragmen teks yang ditempatkan pada koordinat x,y spesifik di halaman. Alat ekstraksi harus:

1. Mengurai operator content stream
2. Menyelesaikan pengodean font untuk memetakan indeks glif ke karakter Unicode
3. Menggunakan matriks teks (Tm/Td) untuk menentukan posisi x,y setiap karakter
4. Merekonstruksi kata, baris, dan kolom dari koordinat tersebut

Kolom yang tampak sejajar sempurna mungkin berada di x=72.0 pada satu baris dan x=72.5 pada baris berikutnya. Algoritma ekstraksi harus mendefinisikan batas kolom dengan toleransi untuk variasi sub-piksel ini.

PDF Bertanda (Tagged) vs. Tidak Bertanda

PDF Bertanda menyertakan pohon struktur logis tersembunyi (mirip tag HTML) yang menandai konten sebagai judul, paragraf, tabel, baris tabel, dan sel tabel. Ini membuat ekstraksi jauh lebih mudah.

PDF Tidak Bertanda tidak memiliki metadata struktural—alat ekstraksi hanya mendapatkan data posisi mentah dan harus menyimpulkan semuanya.

Sebagian besar PDF laporan yang dihasilkan bank tidak bertanda. Bank menghasilkan laporan menggunakan sistem pemrosesan batch (Oracle BI Publisher, SAP Crystal Reports, atau alur kerja cetak-ke-PDF kustom). Peraturan aksesibilitas (ADA/WCAG) mendorong bank menuju PDF bertanda, tetapi adopsinya lambat. Unduhan standar dari sebagian besar bank besar tetap tidak bertanda.

Variasi Tata Letak Laporan Bank

Tidak ada standar industri tentang cara bank memformat laporan PDF mereka. Lima informasi yang sama—tanggal, deskripsi, debit, kredit, saldo—disusun secara berbeda oleh setiap bank.

Kolom Jumlah Tunggal (Bertanda)

Tanggal Deskripsi Jumlah Saldo
01/15/26 DIRECT DEP PAYROLL +3.500,00 5.200,00
01/16/26 POS PURCHASE GROCERY -87,50 5.112,50

Debit bernilai negatif, kredit bernilai positif (atau sebaliknya). Umum di bank yang lebih kecil, serikat kredit, dan bank digital. Lebih mudah diurai karena hanya ada satu kolom jumlah untuk diekstrak.

Kolom Debit/Kredit Terpisah

Tanggal Deskripsi Penarikan  Setoran Saldo
01/15/26 DIRECT DEP PAYROLL 3.500,00 5.200,00
01/16/26 POS PURCHASE GROCERY 87,50 5.112,50

Digunakan oleh Chase, Bank of America, dan banyak bank tradisional. Alat ekstraksi harus mengidentifikasi kolom mana yang berisi jumlah dan menentukan tandanya.

Dikelompokkan berdasarkan Jenis Transaksi

Akun bisnis dan komersial sering mengelompokkan transaksi:

SETORAN DAN KREDIT LAINNYA 01/15  Wire Transfer Masuk REF#12345 10.000,00 01/18  Setoran Cek #4567 2.500,00 Total Setoran 12.500,00
 
CEK DIBAYAR 01/16  Cek #1234 850,00 01/17  Cek #1235 1.200,00 Total Cek Dibayar 2.050,00
 
TRANSAKSI ELEKTRONIK 01/19  ACH PYMT - Vendor Corp 3.200,00 01/20  Transfer Online ke Tabungan 1.000,00 Total Elektronik 4.200,00

Judul bagian menentukan apakah transaksi tersebut debit atau kredit. Baris ringkasan ("Total Setoran") harus diidentifikasi dan dikecualikan dari data transaksi.

Karakteristik Spesifik Bank

• Chase - Kolom debit/kredit terpisah; mengelompokkan berdasarkan "DEPOSITS AND ADDITIONS" dan "ELECTRONIC PAYMENTS" dan "FEES"; deskripsi multi-baris umum untuk detail pedagang
• Bank of America - Kolom penarikan/setoran terpisah; menyertakan bagian "Daily Balance"; header ekstensif dengan nomor akun, periode laporan, nomor routing
• Wells Fargo - Kolom terpisah; menyertakan bagian "DAILY BALANCE SUMMARY"; menyebut unduhan CSV mereka "Comma Delimited"
• Capital One - Tata letak jumlah tunggal yang bersih untuk kartu konsumen; informasi header minimal
• Citi - Sering menyertakan detail transaksi internasional dengan jumlah mata uang asli dan kurs konversi pada baris terpisah

Variasi Susunan Kolom

Selain pertanyaan debit/kredit, urutan kolom tidak terstandarisasi:

• Urutan kolom: Tanggal-Deskripsi-Jumlah-Saldo vs. Tanggal-Jumlah-Deskripsi-Saldo
• Nomor cek: Ada di akun bisnis, tidak ada di akun pribadi
• Nomor referensi: Umum di laporan bisnis, jarang di laporan pribadi
• Saldo berjalan: Per transaksi (paling umum) vs. subtotal harian vs. tidak ada sama sekali

PDF Digital vs. Pindaian

Faktor terpenting yang memengaruhi akurasi konversi adalah apakah PDF Anda digital atau pindaian.

PDF Digital (Asli)

Dibuat secara terprogram oleh sistem bank Anda saat Anda mengunduh laporan. Teks disimpan sebagai operator content stream dengan pengodean font.

• Akurasi: 99%+ untuk ekstraksi teks—tidak ada kesalahan pengenalan
• Kecepatan: Milidetik per halaman
• Privasi: Dapat diproses sepenuhnya di browser Anda—file tidak pernah meninggalkan perangkat Anda
• Ukuran file: Biasanya 50KB–500KB per halaman
• Cara mengidentifikasi: Anda dapat memilih dan menyorot kata-kata individual

PDF Pindaian

Gambar laporan kertas—dibuat dengan memindai atau memotret dokumen fisik. Konten disimpan sebagai gambar raster (terkompresi JPEG, JPEG2000, CCITT, atau Flate).

• Akurasi: 95–99% dengan OCR profesional; 65–70% dengan OCR generik
• Kecepatan: Detik per halaman (memerlukan pemrosesan gambar)
• Privasi: Biasanya memerlukan pemrosesan sisi server (file harus diunggah untuk OCR)
• Ukuran file: 200KB–2MB+ per halaman
• Cara mengidentifikasi: Anda tidak dapat memilih teks apa pun; memperbesar hingga 400% menunjukkan pikselasi

Mengapa Akurasi Pindaian Lebih Penting untuk Data Keuangan

Tingkat akurasi karakter 97% terdengar sangat baik sampai Anda menerapkannya pada data keuangan. Pada laporan dengan 1.000 karakter jumlah, itu berarti 30 karakter salah baca. Satu digit yang salah baca mengubah jumlah transaksi: "Rp1.234,56" menjadi "Rp1.234,86" atau "Rp7.234,56." OCR canggih mencapai akurasi hampir 99%, tetapi kesalahan yang tersisa secara tidak proporsional jatuh pada karakter yang terlihat serupa: 0/O, 1/l/I, 5/S, 8/B, 6/G, dan yang terpenting, koma/titik.

Selalu utamakan unduhan digital. Unduh laporan dari situs web bank Anda daripada memindai kertas. Ini sepenuhnya menghilangkan kesalahan OCR.

Format Keluaran: Analisis Mendalam

Saat Anda mengonversi laporan bank, Anda memilih format keluaran. Setiap format memiliki kekuatan, keterbatasan, dan kasus penggunaan ideal yang berbeda.

Excel (.xlsx)

Standar: Office Open XML (OOXML), distandardisasi sebagai ECMA-376 dan ISO/IEC 29500.

Apa itu: File .xlsx sebenarnya adalah arsip ZIP yang berisi file XML—struktur buku kerja, data sel, gaya, dan string bersama. Inilah sebabnya mengapa file ini dapat menyimpan tipe data (tanggal sebagai tanggal, angka sebagai angka), pemformatan, rumus, dan beberapa lembar.

Mengapa populer untuk laporan bank:

• Tanggal tetap menjadi tanggal (dapat diurutkan, difilter)
• Angka tetap menjadi angka (dapat dijumlahkan, diformat)
• Rumus untuk rekonsiliasi (SUM, VLOOKUP)
• Tabel pivot untuk kategorisasi pengeluaran
• Pemformatan bersyarat untuk menyorot perbedaan
• Bagikan dengan klien yang membutuhkan spreadsheet yang dapat dibaca

Keterbatasan:

• Maksimum 1.048.576 baris (jarang relevan untuk laporan bank)
• Tidak dapat diimpor langsung ke sebagian besar perangkat lunak akuntansi (gunakan QBO/OFX sebagai gantinya)
• Memerlukan Excel, Google Sheets, atau LibreOffice Calc untuk membuka

Terbaik untuk: Tinjauan manual, analisis kustom, rekonsiliasi, pengarsipan, pelaporan klien.

CSV (Comma-Separated Values)

Standar: RFC 4180 (2005) - "Common Format and MIME Type for Comma-Separated Values."

Aturan inti:

• Rekaman dibatasi oleh CRLF (carriage return + line feed)
• Bidang dipisahkan oleh koma
• Bidang yang berisi koma, tanda kutip, atau jeda baris harus diapit tanda kutip ganda
• Tanda kutip ganda di dalam bidang di-escape dengan menggandakannya

Variasi pembatas di lapangan:

• Koma (,) - Standar, digunakan di AS/Inggris
• Titik koma (;) - Digunakan di negara-negara di mana koma adalah pemisah desimal (Prancis, Jerman, Italia, Spanyol, Brasil)
• Tab (\t) - Format TSV, menghindari konflik pembatas

Masalah pengodean:

• UTF-8 direkomendasikan untuk interoperabilitas
• UTF-8 BOM (Byte Order Mark): Tidak diwajibkan oleh standar, tetapi Excel di Windows memerlukannya untuk menampilkan karakter non-ASCII dengan benar (huruf beraksen, simbol mata uang). Tanpa BOM, Excel mungkin menginterpretasikan UTF-8 sebagai Windows-1252, merusak karakter.
• Excel menggunakan titik koma alih-alih koma sebagai pemisah bidang di lokal Eropa

Keterbatasan:

• Tidak ada tipe data—semuanya teks (angka dengan nol di depan rusak, nomor akun panjang menjadi notasi ilmiah)
• Tidak ada dukungan multi-lembar
• Tidak ada pemformatan atau rumus
• Tidak ada metadata (tidak ada informasi akun, tidak ada ID deteksi duplikat)

Terbaik untuk: Kompatibilitas maksimum—hampir setiap program akuntansi, database, dan spreadsheet dapat mengimpor CSV. Pilihan terakhir universal ketika QBO/OFX tidak tersedia.

QBO (QuickBooks Web Connect)

Apa itu: Format impor untuk QuickBooks (Desktop dan Online). File QBO didasarkan pada spesifikasi OFX dengan ekstensi spesifik QuickBooks.

Klarifikasi penting: ".QBO" TIDAK berarti "QuickBooks Online"—singkatan dari format QuickBooks Web Connect dan berfungsi dengan QuickBooks Desktop maupun QuickBooks Online.

Bidang yang diperlukan per transaksi:

• TRNTYPE - Jenis transaksi (DEBIT, CREDIT, CHECK, DEP, DIRECTDEP, DIRECTDEBIT, ATM, POS, XFER, PAYMENT, FEE, SRVCHG, INT, OTHER)
• DTPOSTED - Tanggal dalam format YYYYMMDD
• TRNAMT - Jumlah (negatif untuk debit)
• FITID - ID Transaksi Lembaga Keuangan
• NAME - Penerima/deskripsi

Mengapa FITID penting: QuickBooks melacak setiap FITID yang pernah diimpor untuk setiap akun. Jika transaksi dengan FITID yang sama diimpor lagi, QuickBooks akan melewatinya secara diam-diam—mencegah entri duplikat saat pengguna mengimpor ulang periode laporan yang tumpang tindih. Deteksi duplikat otomatis ini adalah keuntungan terbesar QBO dibandingkan CSV.

Data tambahan: QBO juga membawa ID akun, ID bank (nomor routing), mata uang, nomor cek, memo, dan saldo akhir—kumpulan data terlengkap dari format impor apa pun untuk QuickBooks.

Terbaik untuk: Pengguna QuickBooks (Desktop dan Online). Memberikan pengalaman impor terlengkap dengan deteksi duplikat otomatis dan klasifikasi jenis transaksi.

OFX (Open Financial Exchange)

Sejarah: Dibuat oleh Microsoft, Intuit, dan CheckFree. Versi 1.0 dirilis Februari 1997.

Evolusi versi:

• OFX 1.0–1.6 (1997–1999): Sintaks berbasis SGML (tidak memerlukan tag penutup)
• OFX 2.0+ (2000–sekarang): Berbasis XML (tag penutup yang benar, XML yang terbentuk dengan baik)

Banyak bank masih menghasilkan OFX 1.x (SGML) untuk kompatibilitas maksimum.

Tata kelola saat ini: Pada tahun 2019, konsorsium OFX bergabung ke dalam konsorsium Financial Data Exchange (FDX), yang sekarang mengelola spesifikasi. FDX memiliki lebih dari 200 organisasi anggota dan 76 juta akun konsumen.

Mengapa OFX adalah standar universal: OFX adalah format yang sama yang digunakan saat Anda menghubungkan rekening bank Anda langsung ke perangkat lunak akuntansi melalui umpan bank—format yang sama berfungsi untuk impor file.

Terbaik untuk pengguna Xero: Xero secara otomatis mengimpor file OFX tanpa memerlukan pemetaan kolom manual. Unggah file dan transaksi muncul segera dengan tanggal, jumlah, dan deskripsi yang benar. Juga berfungsi dengan Wave, Sage, FreshBooks, dan sebagian besar perangkat lunak akuntansi.

QFX (Quicken Financial Exchange)

Apa itu: Varian OFX milik Intuit, digunakan secara eksklusif dengan Quicken. File QFX adalah file OFX standar dengan bidang kepemilikan tambahan.

Bidang kepemilikan utama: INTU.BID - Pengidentifikasi Bank Quicken. ID numerik ini memetakan ke bank dalam database internal Quicken. Tanpanya, Quicken menolak mengimpor file.

Perbedaan dari OFX standar:

• Memerlukan INTU.BID di header
• Mungkin menyertakan bidang lain berawalan INTU.*
• Lembaga keuangan membayar biaya lisensi kepada Intuit untuk menyediakan unduhan QFX
• Quicken tidak akan mengimpor file OFX standar tanpa bidang INTU.BID

Terbaik untuk: Pengguna perangkat lunak keuangan pribadi Quicken. Format yang diperlukan—tidak ada alternatif yang berfungsi.

QIF (Quicken Interchange Format)

Apa itu: Format teks biasa lama yang awalnya dikembangkan oleh Intuit untuk Quicken. Pasangan tag-nilai, satu per baris, dengan tag satu karakter: D untuk tanggal, T untuk jumlah, P untuk penerima, L untuk kategori, M untuk memo, N untuk nomor cek, ^ untuk akhir rekaman.

Mengapa diganti: QIF tidak memiliki mekanisme deteksi duplikat (tidak ada padanan FITID), tidak memiliki bidang identifikasi akun, tidak ada informasi routing bank, tidak ada data saldo, dan format tanggal yang tidak konsisten di berbagai implementasi.

Masih relevan: Beberapa perangkat lunak akuntansi (Xero, Sage, GnuCash) masih menerima impor QIF. Berguna untuk migrasi sistem lama.

JSON (JavaScript Object Notation)

Status saat ini: JSON belum menjadi standar untuk file laporan bank, tetapi semakin banyak digunakan dalam:

• API Open Banking (Standar Open Banking Inggris, Grup Berlin PSD2)
• FDX API (Financial Data Exchange - penerus OFX, 200+ organisasi anggota)
• Plaid, Yodlee, MX dan API agregator data lainnya
• Alur kerja pengembang dan otomatisasi

Adopsi yang berkembang: Peraturan Open Banking (PSD2 di Eropa, Bagian 1033 CFPB di AS) mempercepat adopsi API JSON. FDX API menggunakan JSON/REST dengan OAuth 2.0, mewakili arah masa depan pertukaran data keuangan.

Terbaik untuk: Pengembang yang membangun alur kerja otomatis, integrasi fintech, dasbor kustom, dan integrasi API Open Banking.

Perbandingan Format Singkat

Kompatibilitas Perangkat Lunak Akuntansi

Format mana yang diterima perangkat lunak akuntansi Anda?

Aturan praktis: Gunakan QBO untuk QuickBooks, QFX untuk Quicken, OFX untuk yang lain, dan CSV sebagai pilihan universal.

Perbedaan Format Internasional

Jika Anda bekerja dengan laporan bank internasional, Anda akan menemukan perbedaan format yang membingungkan sebagian besar alat konversi.

Format Tanggal

Masalah ambiguitas: "03/04/2026" adalah 3 April di AS tetapi 4 Maret di Eropa. Ketika semua tanggal dalam laporan memiliki nilai hari 12 atau kurang, tidak ada cara algoritmik untuk menentukan format yang benar tanpa mengetahui negara asalnya. Alat konversi harus memindai semua tanggal dalam laporan, mencari nilai lebih besar dari 12 untuk menentukan format.

Format Angka

"10.000,45" dari bank Eropa berarti sepuluh ribu empat puluh lima sen—bukan sepuluh koma nol nol nol empat lima. Kesalahan dalam hal ini menghasilkan kesalahan sebesar 10.000x.

Penempatan Simbol Mata Uang

• AS/Inggris: Simbol sebelum jumlah: $1.234,56 / £1.234,56
• Prancis, Jerman, Spanyol: Simbol setelah jumlah: 1.234,56 €
• Irlandia, Belanda: Simbol sebelum: €1.234,56
• Jepang: Simbol sebelum: ¥123.456

Pengodean Karakter

• UTF-8 - Standar universal, mendukung semua skrip
• GBK/GB2312 - Aksara Mandarin Sederhana (digunakan oleh bank Tiongkok)
• Shift_JIS - Jepang (digunakan oleh bank Jepang)
• Big5 - Aksara Mandarin Tradisional (Taiwan, Hong Kong)
• EUC-KR - Korea
• ISO 8859-1 - Eropa Barat
• Windows-1252 - Eropa Barat (lama)
• Windows-1256 - Arab

Membuka laporan bank Tiongkok atau Jepang di sistem AS tanpa deteksi pengodean yang benar menghasilkan karakter yang rusak. PDFSub menangani 130+ bahasa dengan deteksi otomatis format tanggal, format angka, dan pengodean karakter—termasuk Arab dan Ibrani dari kanan ke kiri, karakter CJK, dan semua set karakter Eropa.

Elemen Umum Laporan Bank

Tanggal Transaksi vs. Tanggal Posting vs. Tanggal Nilai

Laporan bank dapat menyertakan beberapa tanggal untuk satu transaksi:

• Tanggal transaksi - Kapan pembelian atau transfer benar-benar terjadi
• Tanggal posting - Kapan bank memproses dan mencatatnya (biasanya 1–3 hari kerja kemudian untuk pembelian kartu kredit)
• Tanggal nilai - Kapan dana benar-benar tersedia (memengaruhi perhitungan bunga, umum di perbankan internasional)

Sebagian besar laporan konsumen hanya menampilkan tanggal posting. Laporan bisnis sering kali menyertakan tanggal transaksi dan posting.

Representasi Debit/Kredit

Bank merepresentasikan debit dan kredit secara berbeda:

• Jumlah bertanda: -87,50 untuk debit, +3.500,00 untuk kredit
• Kolom terpisah: "Penarikan" dan "Setoran"
• Singkatan: "DR" untuk debit, "CR" untuk kredit (umum di Inggris/Commonwealth)
• Tanda kurung: (87,50) untuk debit (konvensi akuntansi)

Saldo Berjalan

• Saldo per transaksi - Diperbarui setelah setiap transaksi (paling umum di laporan konsumen AS)
• Hanya saldo harian - Saldo ditampilkan di akhir setiap hari (umum di laporan bisnis)
• Tidak ada saldo berjalan - Hanya saldo pembukaan dan penutupan (beberapa laporan internasional)

Saldo berjalan berharga untuk validasi: Anda dapat memverifikasi bahwa setiap transaksi secara benar memindahkan saldo dari satu baris ke baris berikutnya.

Informasi Header Standar

Sebagian besar laporan bank mencakup: nama pemegang akun, nomor akun (sering kali sebagian disamarkan), periode laporan, saldo pembukaan dan penutupan, total setoran dan penarikan, serta kode routing/sort bank/SWIFT BIC.

Perlindungan Kata Sandi

Cara Bank Mengenkripsi PDF

Bank biasanya menggunakan enkripsi AES-128 atau AES-256. Ada dua mode perlindungan:

• Kata sandi pengguna (kata sandi buka): Diperlukan untuk membuka file
• Kata sandi pemilik (kata sandi izin): PDF terbuka tetapi pengeditan/penyalinan mungkin dibatasi

Pola Kata Sandi Umum

Pola umum lainnya termasuk 4 digit terakhir nomor akun, ID pelanggan, atau nomor anggota. Bank biasanya mengomunikasikan pola kata sandi saat Anda pertama kali mengaktifkan laporan elektronik.

Tantangan Laporan Multi-Halaman

Laporan panjang (akun bisnis dengan ratusan transaksi) menimbulkan beberapa tantangan ekstraksi:

Transaksi Terpisah

Deskripsi transaksi mungkin dimulai di bagian bawah satu halaman dan berlanjut di bagian atas halaman berikutnya. Konverter harus mendeteksi baris kelanjutan dan menggabungkannya menjadi satu transaksi.

Header dan Footer Berulang

Sebagian besar bank mengulang header kolom di setiap halaman, ditambah nomor halaman, penafian hukum, dan teks pemasaran. Ini harus diidentifikasi dan dikecualikan dari data transaksi.

Baris Kelanjutan

Banyak transaksi memiliki deskripsi multi-baris:

15/01  ACH ELECTRONIC DEBIT VENDOR CORP $3.200,00  $2.000,00 REF#123456789 INVOICE 2026-001 VENDOR CORP ACCOUNTS PAYABLE

Baris 2 dan 3 adalah baris kelanjutan yang termasuk dalam transaksi di baris 1. Baris ini biasanya tidak memiliki tanggal dan jumlah, muncul menjorok pada koordinat x yang sama dengan kolom deskripsi.

Pembawaan Saldo

Beberapa bank menyertakan baris "Balance Forward" atau "Balance Brought Forward" di bagian atas halaman kelanjutan. Ini bersifat informatif, bukan transaksi, dan harus dikecualikan dari data yang diekstrak.

Singkatan Transaksi Umum

Laporan bank menggunakan singkatan yang bervariasi antar institusi:

Standar Industri yang Perlu Anda Ketahui

Format ini digunakan dalam perbankan korporat dan manajemen kas. Anda jarang akan menemuinya secara langsung, tetapi memahaminya menjelaskan mengapa laporan bank bekerja seperti itu.

BAI2 (Bank Administration Institute)

Digunakan untuk manajemen kas otomatis dan rekonsiliasi bank dalam sistem ERP (SAP, Oracle). Format ASCII lebar tetap dengan kode jenis transaksi (misalnya, 165 = kredit ACH pra-otorisasi, 455 = debit ACH, 495 = transfer kawat keluar). Awalnya dirilis pada tahun 1987, sekarang dikelola oleh ASC X9.

SWIFT MT940 / MT942

Laporan bank akhir hari (MT940) dan intraday (MT942) yang digunakan oleh bank di seluruh dunia untuk pelanggan korporat dan departemen kas. SWIFT memproses sekitar 45 juta pesan per hari. Format berbasis tag dengan pengidentifikasi bidang yang dibatasi titik dua.

ISO 20022 (camt.053)

Pengganti berbasis XML modern untuk MT940. Bagian dari standar pesan keuangan universal ISO 20022. Data lebih kaya daripada MT940, tidak ada batasan panjang bidang, XML yang dapat diurai mesin dengan validasi XSD. SWIFT sedang bermigrasi dari pesan MT ke ISO 20022. SEPA (Single Euro Payments Area) mewajibkan format camt untuk pembayaran Eropa.

NACHA ACH

Format file untuk transaksi Automated Clearing House di AS. ASCII lebar tetap, tepat 94 karakter per baris. ACH memproses sekitar 30 miliar transaksi per tahun di AS. Ketika laporan bank Anda menampilkan "ACH CREDIT" atau "ACH DEBIT," transaksi yang mendasarinya dikirimkan dalam format NACHA antar bank.

Memilih Format yang Tepat untuk Alur Kerja Anda

Panduan Keputusan

Gunakan QBO jika: Anda menggunakan QuickBooks (Desktop atau Online). Anda mendapatkan klasifikasi jenis transaksi, deteksi duplikat melalui FITID, dan metadata impor terlengkap.

Gunakan OFX jika: Anda menggunakan Xero, Sage, Wave, atau perangkat lunak lain yang kompatibel dengan OFX. Xero memetakan bidang secara otomatis tanpa konfigurasi kolom manual.

Gunakan QFX jika: Anda menggunakan Quicken. Ini adalah satu-satunya format yang diterima Quicken.

Gunakan Excel jika: Anda perlu meninjau, menganalisis, atau memanipulasi data sebelum mengimpor. Buat tabel pivot, jalankan rumus, atau siapkan laporan.

Gunakan CSV jika: Perangkat lunak Anda tidak tercantum di atas, atau Anda membutuhkan kompatibilitas maksimum di berbagai sistem. Bersiaplah untuk memetakan kolom secara manual.

Gunakan JSON jika: Anda sedang membangun alur kerja otomatis, integrasi API, atau sistem pelaporan kustom.

Tips Pro

• Selalu gunakan QBO/OFX daripada CSV jika perangkat lunak Anda mendukungnya—deteksi duplikat saja sudah mencegah jam pembersihan
• Simpan PDF asli di samping file yang dikonversi—itu adalah jejak audit dan dokumen sumber Anda
• Verifikasi setelah setiap impor—periksa saldo pembukaan/penutupan dan beberapa transaksi acak
• Sesuaikan format dengan perangkat lunak—menggunakan format asli untuk platform akuntansi Anda menghindari pemetaan kolom manual dan mengaktifkan fitur otomatis

Coba Gratis

Siap mengonversi laporan pertama Anda? Unggah PDF sekarang—PDFSub mengonversi ke Excel, CSV, QBO, OFX, QFX, dan JSON. Laporan digital diproses sepenuhnya di browser Anda untuk privasi maksimal. Mulai uji coba gratis 7 hari dengan akses penuh ke semua format.