Melampaui batch: treasury dan pajak real-time di ERP dan bank

Selama dua puluh tahun, keuangan korporat hidup dengan keterlambatan. ERP (SAP S/4HANA, Oracle, atau Odoo) menutup pembukuan hari itu. Tugas terjadwal mengirim berkas CSV datar atau MT940 ke bank melalui SFTP. Tim menunggu sampai pagi berikutnya untuk mengetahui apa yang diterima bank dan apa yang gagal.

Cara kerja itu mulai runtuh di kawasan GCC, Eropa, Timur Tengah, dan Afrika. Dua perubahan membuat berkas batch menjadi risiko bisnis langsung.

Mengapa berkas semalam tidak lagi berfungsi

• Pajak kini diperiksa secara real-time. ZATCA Fase 2 di Arab Saudi, kerangka PINT-AE di Uni Emirat Arab, dan ViDA (VAT in the Digital Age) di Uni Eropa mewajibkan setiap faktur divalidasi sebagai XML dan diberi tanda tangan kriptografis, secara real-time atau mendekatinya, sebelum diterbitkan atau diselesaikan secara sah.

• Pembayaran kini membawa data yang kaya. ISO 20022 menggantikan bidang referensi yang pendek dengan rincian pengiriman dana yang sepenuhnya terstruktur, baik dalam instruksi pembayaran (pain.001) maupun dalam pesan manajemen kas (camt.053 dan camt.054).

Ketika perusahaan menambahkan pengesahan pajak real-time dan ISO 20022 di atas middleware batch lama, hasilnya adalah dana tertahan di perjalanan, rekonsiliasi dilakukan dengan tangan, dan penagihan berhenti setiap kali pemeriksaan gagal.

Mengapa konektor standar tidak memadai di produksi

Konektor integrasi standar menangani kasus sederhana dengan baik. Konektor itu tidak dirancang untuk menjaga konsistensi catatan keuangan ketika ribuan transaksi tiba sekaligus. Di perusahaan yang mapan, tiga masalah muncul berulang kali:

• Data hilang dalam penerjemahan. Tabel ERP kustom jarang dapat dipetakan dengan rapi ke skema ISO 20022 yang ketat atau faktur elektronik UBL 2.1 tanpa lapisan pemetaan yang cermat dan berbasis aturan.

• Duplikat saat percobaan ulang. Ketika bank atau gateway pajak mengalami waktu tunggu habis karena beban, percobaan ulang sederhana dapat mengirim pembayaran yang sama dua kali atau mengirim faktur yang sama dua kali.

• Dua sistem, dua kebenaran. ERP menandai faktur sebagai sudah dicatat, sementara otoritas pajak menolak tanda tangannya. Tim keuangan harus membalik jurnal secara manual di antara sistem yang tidak saling berkomunikasi.

Cara kami membangunnya

Di XSIS, kami memperlakukan integrasi sebagai rekayasa, bukan konfigurasi. Mesin perbendaharaan dan kepatuhan real-time yang andal berdiri di atas empat bagian.

1. Setiap peristiwa ditangkap sekali

Kami tidak melakukan polling pada basis data ERP. Kami menangkap setiap perubahan saat terjadi, melalui outbox transaksional atau event mesh milik ERP sendiri. Setiap peristiwa keuangan mendapat kunci yang stabil berdasarkan asal dokumen, sehingga diproses tepat satu kali di seluruh sistem bank dan pajak.

2. Pemeriksaan sebelum apa pun keluar

Sebelum pesan mencapai bank atau portal pajak, mesin validasi terpisah memeriksa XML terhadap skemanya, menerapkan tanda tangan kriptografis (CSID atau X.509), dan membuat kode QR serta rantai hash yang diperlukan. Semua ini memakan waktu kurang dari 50 milidetik.

3. Satu format internal untuk setiap bank

Model data internal berversi berada di antara ERP dan dunia luar. Menambah bank baru, atau berpindah dari pesan MT ke pesan MX, tidak berarti menulis ulang kode ABAP atau PL/SQL di ERP.

4. Rekening koran dicocokkan secara otomatis

Rekening koran (camt.053) dan pemberitahuan pembayaran instan (camt.054) dibaca dan dicocokkan dengan piutang terbuka berdasarkan aturan yang jelas. Lebih dari 99% item direkonsiliasi tanpa langkah manual, dan hanya pengecualian nyata yang sampai ke staf.

Dari mana memulai

Anda tidak perlu mengganti ERP untuk mengakhiri penundaan batch. Mulailah dengan Brownfield Diagnostic Bridge: dalam 1 hingga 2 minggu, kami memetakan di mana data hilang antara ERP, middleware, dan bank Anda. Setelah itu, Anda memindahkan putaran rekonsiliasi yang paling menyakitkan ke real-time terlebih dahulu.