Integrasi Coretax DJP dengan SAP atau Odoo: Alur API dari ERP ke e-Faktur, VSWP, dan Status DJP

Terbit: 5 November 2026 · Diperbarui: 5 November 2026 · Ditulis oleh Tim Pajak Sipajak

Integrasi Coretax DJP dengan SAP atau Odoo adalah koneksi dari lapisan integrasi ERP ke modul e-Faktur yang terintegrasi dengan sistem DJP, misalnya lewat API milik PJAP. ERP memvalidasi NPWP pembeli, mengirim data faktur saat dokumen penjualan diposting, lalu menyimpan nomor faktur dan status dari DJP, jadi tim tidak perlu mengunggah file atau mengetik ulang.

Ringkasan Eksekutif

• PER-11/PJ/2025 Pasal 40 mengizinkan e-Faktur dibuat lewat Portal Wajib Pajak atau lewat aplikasi lain yang terintegrasi dengan sistem DJP. Pasal 41 membuka jalur itu lewat PJAP yang ditunjuk DJP.
• Di ERP, ada lima titik panggilan API: master data pelanggan, posting dokumen penjualan, koreksi faktur, rekonsiliasi status, serta pembayaran dan pelaporan.
• Validasi NPWP pembeli sebaiknya terjadi di master data. Kesalahan identitas pembeli tidak bisa diperbaiki dengan Faktur Pajak pengganti, tetapi harus dibatalkan lalu dibuat faktur baru (PER-11/PJ/2025 Pasal 48 dan 49).
• Error bisnis DJP di API e-Faktur Sipajak kembali sebagai HTTP 200 dengan data.status "0". Retry otomatis hanya untuk HTTP 500, 502, dan 504.
• Tidak ada header Idempotency-Key. Endpoint create mengandalkan natural key, jadi lapisan integrasi perlu mencatat setiap pengiriman per dokumen ERP.

Fakta Singkat

• Definisi: integrasi Coretax dari ERP adalah pengiriman data faktur, validasi NPWP, kode billing, dan SPT dari SAP, Odoo, atau ERP lain ke DJP lewat API yang terhubung host-to-host.
• Dasar hukum: PER-11/PJ/2025 Pasal 33, 37, 40 sampai 44, 48, dan 49, serta PMK 131/2024 Pasal 3 untuk penghitungan PPN.
• Berlaku sejak: PER-11/PJ/2025 berlaku sejak ditetapkan pada 22 Mei 2025. PMK 131/2024 berlaku mulai 1 Januari 2025.
• Siapa terdampak: Pengusaha Kena Pajak (PKP) yang membuat e-Faktur dari ERP, serta tim IT yang membangun integrasinya.
• Sistem terkait: Coretax DJP (modul e-Faktur), ERP seperti SAP dan Odoo, dan API Sipajak versi /v1/ dan /v2/ (VSWP, e-Faktur, e-Billing, SPT).
• Terakhir diverifikasi: 5 November 2026.

Apa itu integrasi Coretax DJP dengan SAP atau Odoo?

Integrasi Coretax DJP dengan SAP atau Odoo berarti ERP kamu memanggil API dari lapisan integrasinya setiap kali ada kejadian pajak, misalnya posting faktur penjualan. API itu meneruskan data ke modul e-Faktur DJP dan mengembalikan nomor serta status faktur ke ERP. Tim finance tidak lagi menyiapkan file terpisah untuk diunggah.

Dasarnya ada di PER-11/PJ/2025. Pasal 40 ayat (1) menyebut e-Faktur dibuat memakai modul dalam Portal Wajib Pajak atau laman atau aplikasi lain yang terintegrasi dengan sistem administrasi DJP. Pasal 41 ayat (1) menambahkan bahwa modul di aplikasi terintegrasi itu bisa dipakai PKP yang membuat e-Faktur melalui penyedia jasa aplikasi perpajakan (PJAP) yang ditunjuk Direktur Jenderal Pajak.

Jadi, yang kamu bangun bukan koneksi langsung ke DJP. Sipajak adalah Penyedia Jasa Aplikasi Perpajakan (PJAP) resmi yang terdaftar dan diawasi DJP, menyediakan API pajak end-to-end, platform, dan solusi white-label. REST API Sipajak bisa dipanggil SAP, Odoo, atau ERP lain dari lapisan integrasinya, misalnya middleware, job terjadwal, atau modul kustom. Kalau kamu butuh gambaran umum akses portal dan API, baca dulu panduan akses portal dan API Coretax DJP. Artikel ini fokus pada sisi ERP-nya.

Syarat apa yang harus dimiliki PKP sebelum ERP membuat e-Faktur?

PKP harus punya Sertifikat Elektronik atau Kode Otorisasi dan akses pembuatan Faktur Pajak (PER-11/PJ/2025 Pasal 42 ayat (1)). Di API e-Faktur Sipajak, syarat ini muncul sebagai field penandatangan di setiap request yang membuat atau mengubah faktur: npwpNikPenandatangan, userId, tempatPenandatangan, dan passphrasePenandatangan.

Sertifikatnya sendiri didaftarkan sekali saat onboarding organisasi. Passphrase dikirim sebagai teks di body request, jadi hanya boleh lewat TLS, tidak boleh masuk log, dan sebaiknya disimpan di secrets manager.

Di titik mana ERP memanggil API Coretax lewat PJAP?

ERP memanggil API di lima titik: saat master data pelanggan dibuat, saat dokumen penjualan diposting, saat faktur dikoreksi, saat status direkonsiliasi, dan saat pajak dibayar atau dilaporkan. Titiknya sama di SAP, Odoo, maupun ERP lain. Yang berbeda hanya tempat kamu memasang pemicunya di lapisan integrasi.

1. Master data pelanggan dibuat atau diubah. Lapisan integrasi memanggil POST /v2/vswp untuk mengecek NPWP atau NIK pelanggan. Untuk data lama dalam jumlah besar, pakai POST /v1/vswp/bulking.
2. Dokumen penjualan diposting. ERP mengirim POST /v2/efaktur/create-faktur-pk dengan data header, pembeli, baris barang atau jasa, total, dan penandatangan.
3. Faktur dikoreksi. Pengganti memakai create-faktur-pk-amended, pembatalan memakai cancel-faktur-pk, dan retur dari pembeli dibaca lewat create-retur-faktur-pk.
4. Status direkonsiliasi. Untuk faktur yang masih SIGNING_IN_PROGRESS, panggil POST /v2/efaktur/check-status saat rekonsiliasi, bukan sebagai polling terus-menerus.
5. Pajak dibayar dan dilaporkan. Modul e-Billing membuat ID Billing, dan modul SPT menjalankan alur SPT sampai Bukti Penerimaan Elektronik (BPE).

Semua request memakai HTTP Basic Auth dan header npwp yang menyebut organisasi yang diwakili. Detail base URL dan aturan versi ada di panduan memulai: base URL, Basic Auth, dan header npwp.

Kenapa validasi NPWP pembeli harus terjadi di master data?

Validasi NPWP pembeli harus terjadi di master data karena salah isi identitas pembeli tidak bisa diperbaiki dengan Faktur Pajak pengganti. PER-11/PJ/2025 Pasal 48 ayat (2) mengecualikan kesalahan identitas pembeli dari pembetulan. Pasal 49 ayat (2) dan (3) mewajibkan faktur seperti itu dibatalkan, lalu dibuat faktur baru dengan identitas yang sebenarnya.

Identitas yang wajib ada di faktur diatur Pasal 33 huruf b. Untuk Wajib Pajak dalam negeri badan dan instansi pemerintah, isinya nama, alamat, dan NPWP. Untuk orang pribadi dalam negeri, isinya nama, alamat, dan NPWP atau NIK. Untuk orang pribadi luar negeri, isinya nama, alamat, dan nomor paspor.

Di API Validasi Status Wajib Pajak (VSWP), endpoint POST /v2/vswp menerima NPWP 15 digit, NPWP 16 digit, atau NIK 16 digit, dan mengembalikan nama, alamat, statusWp, dan statusSpt. Ada dua perilaku yang perlu kamu tangani di ERP:

• Tidak ada validasi format. Input yang salah format dan NPWP yang tidak terdaftar sama-sama menghasilkan pesan "Wajib Pajak tidak ditemukan". Cek panjang dan format di ERP lebih dulu.
• Hasil di-cache 90 hari per pasangan npwp dan tujuan. Artinya, pengecekan ulang dalam periode itu tidak memanggil DJP lagi, jadi jadwalkan validasi ulang sesuai kebutuhan kepatuhan kamu.

Pesan pertama di katalog error e-Faktur Sipajak adalah "npwpPembeli tidak ditemukan". Validasi di master data mencegah pesan itu muncul di tengah batch faktur.

Bagaimana alur dari posting dokumen sampai faktur terbit?

Alur dari posting dokumen sampai faktur terbit punya enam langkah: tandai dokumen, petakan payload, kirim create-faktur-pk dengan nomorFaktur kosong, lalu baca data.status. Hasilnya ada tiga: faktur APPROVED dengan nomor dari DJP, faktur yang masih SIGNING_IN_PROGRESS, atau dokumen yang masuk antrean error.

1. ERP memposting dokumen penjualan dan menandainya "siap kirim".
2. Lapisan integrasi memetakan field ERP ke payload. Nomor dokumen ERP masuk ke field referensi.
3. Field nomorFaktur dikosongkan. Menurut PER-11/PJ/2025 Pasal 43, Nomor Seri Faktur Pajak diberikan otomatis saat e-Faktur diunggah dan disetujui DJP.
4. Jika data.status "1" dan statusFaktur APPROVED, simpan nomorFaktur dan idFaktur di dokumen ERP.
5. Jika statusFaktur SIGNING_IN_PROGRESS, tandai dokumen "menunggu" dan cek lagi saat rekonsiliasi.
6. Jika data.status "0", pindahkan dokumen ke antrean error beserta isi statusMessage.

Kode dan nomor seri faktur terdiri atas 17 digit: 2 digit kode transaksi, 2 digit kode status, dan 13 digit Nomor Seri Faktur Pajak dari DJP (PER-11/PJ/2025 Pasal 37 ayat (1)). Simpan apa adanya, karena nomor ini dipakai lagi untuk pengganti, pembatalan, dan pengecekan status. Penjelasan protokol host-to-host yang lebih umum ada di artikel cara kerja e-Faktur host-to-host saat DJP downtime.

Contoh payload create faktur (data fiktif)

Contoh berikut memakai field dari dokumentasi API e-Faktur Sipajak. Semua NPWP, nama, dan nilai adalah data fiktif. Kode transaksi dan kode satuan diambil dari endpoint referensi, bukan diketik manual.

POST /v2/efaktur/create-faktur-pk
Host: staging-gateway-integration.sipajak.com
Authorization: Basic <base64(username:password)>
npwp: 1234567890123000
Content-Type: application/json

{
  "fgUangMuka": false,
  "fgPelunasan": false,
  "nomorFaktur": null,
  "tanggalFaktur": "05112026",
  "detailTransaksi": "<kode TD.003xx dari /v1/ref/transaction-code>",
  "idKeteranganTambahan": "",
  "keteranganTambahan": "",
  "masaPajak": "11",
  "tahunPajak": "2026",
  "referensi": "SO-2026-11-0003",
  "npwpPenjual": "1234567890123000",
  "namaTokoPenjual": "1234567890123000000000",
  "npwpPembeli": "2345678901234000",
  "tkuPembeli": "2345678901234000000000",
  "kdNegaraPembeli": "IDN",
  "namaPembeli": "PT Pembeli Fiktif",
  "alamatPembeli": "Jalan Contoh No. 2, Bandung 40000",
  "emailPembeli": null,
  "objekFaktur": [
    {
      "brgJasa": "SERVICES",
      "kdBrgJasa": "000000",
      "namaBrgJasa": "Jasa pemeliharaan mesin (fiktif)",
      "satuanBrgJasa": "<kode UM.xxxx dari /v1/ref/unit>",
      "hargaSatuan": 7200000,
      "jmlBrgJasa": 1,
      "totalHarga": 7200000,
      "diskon": 0,
      "cekDppLain": true,
      "dpp": 7200000,
      "dppLain": 6600000,
      "tarifPpn": 0.12,
      "ppn": 792000,
      "tarifPpnbm": 0,
      "ppnbm": 0
    }
  ],
  "jumlahUangMuka": 0,
  "totalDpp": 7200000,
  "totalDppLain": 6600000,
  "totalPpn": 792000,
  "totalPpnbm": 0,
  "npwpNikPenandatangan": "<NIK penandatangan>",
  "tempatPenandatangan": "Jakarta",
  "passphrasePenandatangan": "<dari secrets manager, jangan di-log>",
  "userId": "<NIK penandatangan>",
  "kanal": "08",
  "idKanal": "08"
}

Tanggal di body e-Faktur memakai format DDMMYYYY tanpa pemisah, masaPajak berupa string dua digit, dan tahunPajak berupa string empat digit. Tarif dikirim sebagai pecahan desimal, jadi 12% ditulis 0.12.

Contoh hitungan satu batch dari ERP (data fiktif)

Untuk barang dan jasa yang tidak tergolong mewah, PPN dihitung dengan tarif 12% dikalikan Dasar Pengenaan Pajak berupa nilai lain sebesar 11/12 dari harga jual atau penggantian (PMK 131/2024 Pasal 3 ayat (2) dan (3)). Di payload, nilai itu masuk ke dppLain dengan cekDppLain bernilai true. Tabel ini memakai tiga dokumen penjualan fiktif yang diposting pada 5 November 2026.

Hasil rekonsiliasinya: PPN dari faktur yang sudah terbit Rp1.232.000 (Rp440.000 + Rp792.000), dan Rp1.375.000 masih tertahan di antrean error. Dokumen SO-2026-11-0002 baru dikirim ulang setelah NPWP pembelinya diperbaiki dan lolos VSWP. Dokumen SO-2026-11-0003 boleh dicoba ulang otomatis karena HTTP 504 adalah gangguan transport, bukan penolakan data.

Bagaimana menangani error dan retry saat DJP gangguan?

Tangani error dengan memisahkan dua jenis kegagalan: error bisnis DJP yang butuh perbaikan data, dan error transport yang boleh dicoba ulang. Di API e-Faktur dan VSWP Sipajak, error bisnis kembali sebagai HTTP 200 dengan data.status "0". HTTP 500, 502, dan 504 aman dicoba ulang dengan exponential backoff.

Pola ini dijelaskan di konvensi API Sipajak tentang soft-error dan retry. Tabel berikut menerjemahkannya menjadi aturan antrean di ERP.

Hati-hati dengan check-status. Endpoint ini selalu mengembalikan HTTP 201 dengan data null, apa pun hasil dari DJP. Status yang benar dibaca dari dokumen di Sipajak setelahnya. Karena setiap panggilan check-status menghubungi DJP, jalankan hanya saat rekonsiliasi atau saat detail dokumen dibuka.

Modul e-Billing dan SPT memakai konvensi berbeda: error bisnis DJP dikembalikan sebagai HTTP 400 dengan envelope asli di body.response. Saat DJP gangguan, e-Billing mengembalikan HTTP 400 dengan pesan "Terjadi kendala, silahkan hubungi admin! (Code: 01)", dan dokumentasi menyarankan retry dengan backoff. Jadi, buat aturan cabang error per modul, bukan satu aturan untuk semua.

Antrean error juga punya batas waktu dari sisi regulasi. PER-11/PJ/2025 Pasal 44 ayat (1) mewajibkan e-Faktur diunggah dan disetujui DJP paling lambat tanggal 20 bulan berikutnya setelah tanggal pembuatan e-Faktur. Menurut ayat (3), e-Faktur yang tidak memperoleh persetujuan bukan merupakan Faktur Pajak.

Bagaimana retry tanpa membuat faktur ganda?

Retry aman dilakukan selama lapisan integrasi mencatat setiap pengiriman per dokumen ERP dan memperlakukan error duplikat sebagai sukses. API Sipajak belum punya header Idempotency-Key. Endpoint yang membuat record, seperti create-faktur-pk, idempoten berdasarkan natural key: pengiriman ulang tuple yang sama ditolak DJP dengan error bisnis, bukan menjadi data ganda.

Dokumentasi memberi contoh natural key nomorFaktur dan tahunPajak. Karena nomorFaktur masih kosong saat create pertama, uji skenario timeout di staging sebelum go-live. Simpan referensi (nomor dokumen ERP), waktu kirim, dan uuid setiap request agar tim bisa menelusuri satu dokumen dari ERP sampai DJP.

Langkah manual apa yang hilang dibanding unggah file atau ketik ulang?

Langkah manual yang hilang adalah menyiapkan data di luar ERP, mengetik atau mengunggahnya ke DJP, lalu menyalin nomor dan status faktur kembali ke ERP. Dengan API, data transaksi terkirim dari sistem kamu tanpa unggah file atau ketik ulang, dan status per transaksi kembali ke sistem yang sama.

Untuk perbandingan lengkap ketiga jalur pembuatan faktur, lihat perbandingan input manual, aplikasi PJAP, dan API.

Modul pajak apa lagi yang bisa disinkronkan dari ERP?

Selain e-Faktur keluaran, ERP bisa menyinkronkan empat modul lain lewat API Sipajak: faktur masukan, e-Billing, SPT, dan validasi NPWP vendor. Autentikasi dan header npwp-nya sama, tetapi konvensi error dan idempotensinya berbeda per modul.

• Faktur masukan (modul AP). POST /v2/efaktur/create-faktur-pm menarik data faktur dari pemasok yang sudah ada di DJP, lalu mengatur periode pengkreditannya.
• e-Billing. POST /v2/ebilling/inquiry mengecek NPWP dan kombinasi kode akun pajak, lalu POST /v2/ebilling/create membuat ID Billing. Request create yang identik dalam satu jam memakai traceId yang sama, dan field external_id bisa dipakai untuk mengatur idempotensi sendiri.
• SPT. Alurnya berurutan: inquiry-max-rev-no, create-spt, inquiry-spt, upload, submit-spt, lalu verify-spt sampai BPE terbit.
• Validasi vendor. POST /v1/vswp/bulking memproses file CSV berisi NPWP untuk penyaringan berkala. Job bulk tidak idempoten, jadi jangan mengirim file yang sama dua kali.

Untuk tim IT & finance

• Simpan kredensial Basic Auth dan passphrasePenandatangan di secrets manager, dan pastikan keduanya tidak tercatat di log.
• Daftarkan setiap NPWP ke kredensial lewat POST /v1/organization sebelum dipakai di header npwp.
• Validasi NPWP pelanggan dengan POST /v2/vswp saat master data dibuat, dan cek format di ERP lebih dulu.
• Isi field referensi dengan nomor dokumen ERP, lalu simpan nomorFaktur, idFaktur, statusFaktur, dan uuid per dokumen.
• Buat cabang error per modul: data.status untuk e-Faktur dan VSWP, HTTP 400 untuk e-Billing dan SPT.
• Batasi retry otomatis ke HTTP 500, 502, dan 504 dengan exponential backoff.
• Pastikan NIK penandatangan terdaftar sebagai pihak yang berhak membuat faktur.
• Tim finance memantau antrean error setiap hari kerja, mengingat batas persetujuan e-Faktur di Pasal 44 PER-11/PJ/2025.
• Uji semua skenario di staging, termasuk timeout dan NPWP tidak ditemukan, sebelum meminta kredensial production.

Mulai integrasi dari staging

Sipajak (PT Hexa Sarana Intermedia) adalah PJAP dengan dasar hukum KEP-423/PJ/2021 tanggal 15 Oktober 2021, seperti tercantum di profil PJAP pada laman DJP. Profil itu mencatat layanan Penyelenggaraan e-Faktur Host-to-Host (H2H), aplikasi pembuatan Kode Billing, penyaluran SPT, bukti pemotongan elektronik, dan Validasi Status Wajib Pajak.

Lewat layanan e-Faktur host-to-host PJAP resmi Sipajak, tim kamu menghubungkan ERP ke Coretax DJP tanpa membangun koneksi sendiri. Staging adalah satu-satunya environment untuk uji integrasi. Kredensial staging diberikan lebih dulu, lalu kredensial production setelah integrasi staging kamu terverifikasi.

Minta Akses API di halaman dokumentasi Sipajak untuk mendapatkan kredensial staging.

Pertanyaan umum

Sumber & Dasar Hukum

• PER-11/PJ/2025 tentang Ketentuan Pelaporan PPh, PPN, PPnBM, dan Bea Meterai dalam rangka Pelaksanaan Sistem Inti Administrasi Perpajakan: Pasal 33, 37, 40 sampai 44, 48, dan 49. Ditetapkan dan berlaku 22 Mei 2025.
• PMK 131 Tahun 2024: Pasal 3 ayat (2) dan (3). Ditetapkan 31 Desember 2024, berlaku 1 Januari 2025.
• Profil PJAP PT Hexa Sarana Intermedia di pajak.go.id: dasar hukum KEP-423/PJ/2021 dan daftar layanan.
• Dokumentasi API Sipajak versi 1.8, diperbarui 29 Desember 2025: modul Memulai, Konvensi API, VSWP, e-Faktur, e-Billing, dan SPT (sipajak.com/developers).

Terbit: 5 November 2026 · Diperbarui: 5 November 2026 · Ditulis oleh Tim Pajak Sipajak

Artikel ini bersifat edukasi, bukan nasihat pajak. Untuk kasus spesifik, konsultasikan dengan konsultan pajak terdaftar.