Studi Kasus Coretax e-Bupot: Mengatasi Kesalahan Bukti Potong di Perusahaan
Bagi perusahaan yang melakukan pemotongan pajak atas berbagai transaksi, bukti potong merupakan bagian penting dari administrasi perpajakan.
Namun, semakin banyak transaksi yang dikelola, semakin besar pula kemungkinan munculnya kesalahan.
Bayangkan sebuah perusahaan memiliki ratusan vendor dan melakukan berbagai transaksi setiap bulan.
Tim Tax harus memastikan bahwa setiap transaksi yang menjadi objek pemotongan pajak memiliki administrasi yang tepat.
Masalah kemudian muncul:
- identitas vendor tidak sesuai;
- jenis penghasilan salah;
- nominal pada bukti potong berbeda dengan invoice;
- transaksi belum dibuatkan bukti potong;
- bukti potong dibuat dua kali;
- data Tax berbeda dengan Accounting;
- revisi transaksi tidak segera diketahui oleh Tax.
Pada kondisi seperti ini, masalahnya tidak selalu terletak pada kemampuan menggunakan Coretax.
Sering kali akar masalahnya justru berada pada:
Data + People + Process + Control.
Artikel ini membahas beberapa studi kasus Coretax e-Bupot yang dapat terjadi dalam administrasi perusahaan, sekaligus membahas root cause dan langkah pencegahannya.
Catatan: Studi kasus dalam artikel ini bersifat ilustrasi untuk tujuan edukasi. Penanganan transaksi aktual harus disesuaikan dengan jenis transaksi, ketentuan perpajakan, dan prosedur Coretax yang berlaku.
Mengapa e-Bupot Perlu Mendapat Perhatian?
e-Bupot bukan sekadar dokumen yang dibuat setelah transaksi.
Prosesnya berkaitan dengan rangkaian aktivitas:
Transaksi
↓
Identifikasi Objek Pajak
↓
Perhitungan
↓
Pemotongan
↓
Bukti Potong
↓
Pelaporan
Karena itu, kesalahan pada satu tahap dapat berdampak pada tahap berikutnya.
DJP menjelaskan bahwa bukti pemotongan/pemungutan elektronik merupakan salah satu dokumen elektronik yang digunakan dalam proses administrasi dan persiapan SPT Masa di Coretax.
Studi Kasus 1: Nama dan Identitas Vendor Tidak Sesuai
Kondisi
PT Maju Bersama menggunakan data vendor dari sistem Accounting untuk membuat bukti potong.
Suatu hari, vendor menghubungi perusahaan karena informasi pada bukti potong tidak sesuai dengan data mereka.
Tim Tax kemudian menemukan bahwa database vendor yang digunakan belum diperbarui.
Data di sistem:
PT ABC Indonesia
Sedangkan data terbaru vendor:
PT ABC Indonesia Tbk
Masalah terlihat sederhana.
Namun jika terjadi pada ratusan vendor, proses perbaikannya bisa menjadi pekerjaan besar.
Apa Root Cause-nya?
Kesalahan bukan semata-mata karena Tax salah input.
Akar masalahnya adalah:
Master Data Vendor tidak memiliki proses validasi berkala.
Workflow perusahaan sebelumnya:
Vendor
↓
Procurement
↓
Accounting
↓
Tax
Tidak terdapat checkpoint:
Data Validation
Solusi
Buat Vendor Tax Master Data yang memiliki informasi relevan untuk kebutuhan perpajakan.
Contohnya:
| Data | Status |
| Nama vendor | ✓ |
| Identitas perpajakan | ✓ |
| Alamat | ✓ |
| Status/data relevan | ✓ |
| Dokumen pendukung | ✓ |
| Tanggal update | ✓ |
Kemudian buat mekanisme:
Vendor Update
↓
Verification
↓
Approval
↓
Tax Master Data
Dengan begitu, Tax tidak perlu melakukan verifikasi ulang dari awal untuk setiap transaksi.
Lesson Learned
Kualitas bukti potong dimulai dari kualitas master data.
Coretax dapat membantu proses administrasi, tetapi sistem tetap membutuhkan data yang benar.
Studi Kasus 2: Salah Menentukan Jenis Penghasilan
Kondisi
Perusahaan membayar sebuah transaksi kepada vendor.
Tax Staff melihat transaksi tersebut dan langsung memilih kategori yang dianggap paling sesuai.
Setelah dilakukan review, ternyata karakteristik transaksi membutuhkan perlakuan perpajakan yang berbeda.
Masalah
Kesalahan bukan terjadi ketika mengetik angka.
Kesalahan terjadi lebih awal:
Salah memahami karakter transaksi.
Mengapa Ini Berbahaya?
Jika jenis transaksi tidak tepat, maka dapat berdampak pada:
- jenis pemotongan;
- dasar pengenaan;
- tarif yang digunakan;
- nilai pajak;
- bukti potong;
- proses pelaporan.
Karena itu, user Coretax harus memahami tax treatment, bukan hanya cara mengoperasikan sistem.
Solusi
Sebelum membuat e-Bupot, gunakan decision flow:
Apa transaksi?
↓
Siapa penerima penghasilan?
↓
Apa jenis penghasilannya?
↓
Apakah merupakan objek pemotongan?
↓
Apa ketentuan yang berlaku?
↓
Buat e-Bupot
Dengan pendekatan ini, sistem digunakan setelah analisis transaksi dilakukan.
Lesson Learned
Jangan mulai dari menu Coretax. Mulailah dari karakter transaksi.
Studi Kasus 3: Nilai Invoice dan Bukti Potong Berbeda
Kondisi
Accounting mencatat invoice:
Rp200.000.000
Namun pada data e-Bupot ditemukan nilai yang berbeda.
Tax Staff mengatakan:
“Saya menggunakan data yang diberikan Finance.”
Finance mengatakan:
“Saya menggunakan data invoice.”
Accounting mengatakan:
“Data invoice sudah berubah.”
Akhirnya tidak ada satu pihak yang mengetahui kapan perubahan tersebut terjadi.
Root Cause
Masalah sebenarnya adalah:
Tidak ada single source of truth.
Masing-masing departemen memiliki data sendiri.
Finance
→ Invoice
Accounting
→ Accounting System
Tax
→ Tax Working File
Akibatnya:
Invoice ≠ Accounting ≠ e-Bupot
Solusi
Buat proses rekonsiliasi:
Invoice
↕
Accounting
↕
e-Bupot
Data harus dibandingkan sebelum periode pelaporan ditutup.
Jika terdapat selisih:
Exception
↓
Investigation
↓
Correction
↓
Close
Lesson Learned
e-Bupot seharusnya tidak berjalan terpisah dari Finance dan Accounting.
Studi Kasus 4: Satu Transaksi Dibuatkan Dua Bukti Potong
Kondisi
Perusahaan memiliki dua Tax Staff.
Keduanya menerima data transaksi yang sama dari departemen berbeda.
Staff A membuat bukti potong.
Beberapa waktu kemudian Staff B juga membuat bukti potong untuk transaksi yang sama.
Akibatnya terjadi potensi duplikasi administrasi.
Mengapa Bisa Terjadi?
Karena perusahaan tidak memiliki:
- unique transaction ID;
- monitoring;
- pembagian PIC;
- status tracking;
- review sebelum penerbitan.
Solusi
Setiap transaksi perlu memiliki identitas yang dapat ditelusuri.
Contohnya:
Invoice Number
atau
Transaction ID
Kemudian gunakan monitoring:
| Invoice | Vendor | Nilai | e-Bupot | PIC | Status |
| INV-001 | Vendor A | Rp… | EB-001 | Tax A | Complete |
| INV-002 | Vendor B | Rp… | EB-002 | Tax B | Complete |
| INV-003 | Vendor C | Rp… | – | Tax A | Pending |
Dengan monitoring tersebut, transaksi yang sudah diproses lebih mudah dikenali.
Lesson Learned
Volume transaksi yang tinggi membutuhkan kontrol terhadap duplikasi.
Studi Kasus 5: Transaksi Sudah Dibayar, tetapi Belum Ada e-Bupot
Kondisi
Finance telah melakukan pembayaran kepada vendor.
Namun ketika Tax melakukan review, transaksi tersebut belum masuk dalam daftar bukti potong.
Workflow sebelumnya:
Invoice
↓
Payment
Tetapi tidak ada notifikasi:
Payment → Tax
Akibatnya Tax baru mengetahui transaksi tersebut ketika melakukan review akhir periode.
Root Cause
Tidak ada integrasi workflow antara Finance dan Tax.
Informasi transaksi hanya berpindah melalui:
- email;
- spreadsheet;
- WhatsApp;
- komunikasi manual.
Solusi
Buat trigger yang jelas.
Misalnya:
Invoice Approved
↓
Tax Assessment
↓
Payment
↓
e-Bupot
atau sesuai workflow perusahaan:
Invoice
↓
Tax Assessment
↓
Payment
↓
Bukti Potong
Yang penting, tanggung jawab setiap tahapan ditetapkan dengan jelas.
Lesson Learned
Transaksi yang sudah dibayar harus dapat ditelusuri status administrasi pajaknya.
Studi Kasus 6: Revisi Invoice Tidak Diketahui Tax
Kondisi
Vendor mengajukan perubahan invoice.
Finance kemudian memperbarui dokumen.
Namun Tax masih menggunakan data lama ketika melakukan administrasi bukti potong.
Akibatnya:
Invoice terbaru ≠ e-Bupot
Mengapa Ini Terjadi?
Perusahaan memiliki prosedur:
Invoice Revision
tetapi tidak memiliki:
Tax Impact Assessment.
Solusi
Setiap perubahan transaksi perlu menjawab:
1. Apa yang berubah?
Nilai?
Vendor?
Tanggal?
Jenis transaksi?
2. Apakah perubahan berdampak pada pajak?
Jika ya:
Tax Review
3. Apakah bukti potong perlu disesuaikan?
Jika ya:
Follow-up sesuai ketentuan
Workflow yang Disarankan
Invoice Revision
↓
Notify Tax
↓
Tax Impact Assessment
↓
Review e-Bupot
↓
Correction/Adjustment jika diperlukan
↓
Documentation
Lesson Learned
Revisi invoice bukan hanya masalah Finance. Perubahan transaksi harus dilihat juga dari perspektif perpajakan.
Studi Kasus 7: e-Bupot Tidak Direkonsiliasi dengan Accounting
Kondisi
Pada akhir bulan:
Accounting
mencatat transaksi vendor sebesar:
Rp3 miliar
Sedangkan rekap Tax menunjukkan:
Rp2,7 miliar
Ada selisih:
Rp300 juta.
Masalahnya, tidak ada yang tahu transaksi mana yang menyebabkan perbedaan.
Apa yang Salah?
Perusahaan melakukan:
Input
tetapi tidak melakukan:
Reconciliation.
Padahal rekonsiliasi dapat membantu menemukan:
- transaksi belum diproses;
- transaksi terduplikasi;
- transaksi salah periode;
- transaksi salah klasifikasi;
- transaksi yang datanya belum lengkap.
Solusi: Rekonsiliasi Berkala
Gunakan:
Accounting
vs.
Vendor Payment
vs.
e-Bupot
Contoh:
| Parameter | Accounting | e-Bupot | Selisih |
| Jumlah transaksi | 500 | 485 | 15 |
| Nilai transaksi | Rp3 M | Rp2,7 M | Rp300 Jt |
| Vendor | 250 | 245 | 5 |
Selanjutnya buat exception list untuk setiap perbedaan.
Lesson Learned
Rekonsiliasi bukan pekerjaan tambahan. Rekonsiliasi adalah kontrol untuk menemukan kesalahan sebelum menjadi masalah yang lebih besar.
Studi Kasus 8: Hanya Satu Orang yang Menguasai e-Bupot
Kondisi
Perusahaan memiliki satu Tax Staff yang sangat memahami Coretax.
Dia mengetahui:
- cara input;
- cara membuat bukti potong;
- cara menangani error;
- cara melakukan pengecekan;
- cara melakukan rekonsiliasi.
Ketika orang tersebut tidak masuk, proses menjadi lambat.
Root Cause
Key Person Dependency.
Knowledge perusahaan tersimpan pada individu, bukan pada sistem dan SOP.
Solusi
Perusahaan perlu membangun:
SOP
Dokumentasikan workflow.
Backup PIC
Siapkan orang kedua.
Knowledge Sharing
Lakukan transfer knowledge.
Training
Pastikan beberapa orang memahami proses.
Idealnya:
Maker
Checker
Backup
memiliki pemahaman yang cukup terhadap workflow.
Lesson Learned
Jangan biarkan Coretax hanya dikuasai oleh satu orang.
Studi Kasus 9: Data e-Bupot Berhasil Diproses, tetapi Tidak Direview
Kondisi
Tim Tax menggunakan proses input/import data dalam jumlah besar.
Sistem menunjukkan proses berhasil.
Tim kemudian menganggap pekerjaan selesai.
Namun saat dilakukan pengecekan lebih lanjut, terdapat data yang tidak sesuai.
Apa Masalahnya?
Ada perbedaan antara:
Technical Success
dan
Business Accuracy.
Data berhasil diproses sistem belum tentu berarti seluruh data sudah benar secara substantif.
Solusi
Buat dua tahap pemeriksaan:
Technical Validation
Apakah data berhasil diproses?
Substantive Review
Apakah datanya benar?
Keduanya berbeda.
Lesson Learned
“Berhasil masuk sistem” tidak selalu berarti “sudah benar”.
Pola Masalah dari Seluruh Studi Kasus
Jika semua kasus di atas dianalisis, terdapat pola yang sama.
| Kasus | Masalah Utama |
| Identitas vendor salah | Master data |
| Jenis penghasilan salah | Tax knowledge |
| Invoice ≠ e-Bupot | Data integration |
| Duplikasi bukti potong | Monitoring |
| Transaksi belum dibuatkan e-Bupot | Workflow |
| Revisi invoice tidak diketahui Tax | Communication |
| Tax ≠ Accounting | Reconciliation |
| Bergantung satu orang | SDM |
| Data berhasil tetapi tidak akurat | Review |
Jadi, masalah Coretax e-Bupot sebenarnya dapat dikelompokkan menjadi:
DATA
PEOPLE
PROCESS
SYSTEM
CONTROL
Framework Pengendalian Coretax e-Bupot
Untuk mengurangi risiko, perusahaan dapat menggunakan framework berikut.
1. Data
Pastikan master data dan transaksi akurat.
↓
2. Tax Assessment
Pastikan perlakuan pajak benar.
↓
3. Input/Import
Masukkan data ke Coretax.
↓
4. Validation
Pastikan data berhasil dan benar.
↓
5. Review
Lakukan pemeriksaan.
↓
6. Reconciliation
Bandingkan dengan Accounting.
↓
7. Monitoring
Pantau transaksi dan status.
↓
8. Documentation
Pastikan seluruh proses dapat ditelusuri.
Checklist Pengendalian e-Bupot Perusahaan
DATA
☐ Data vendor benar
☐ Identitas perpajakan benar
☐ Invoice tersedia
☐ Data transaksi lengkap
TAX
☐ Jenis transaksi sudah dianalisis
☐ Objek pajak sudah ditentukan
☐ Perhitungan sudah direview
CORE TAX
☐ Data diinput/import dengan benar
☐ Status proses diperiksa
☐ Bukti potong tersedia
CONTROL
☐ Maker-checker tersedia
☐ Tidak ada duplikasi
☐ Revisi transaksi dimonitor
RECONCILIATION
☐ Invoice sesuai
☐ Payment sesuai
☐ Accounting sesuai
☐ e-Bupot sesuai
DOCUMENTATION
☐ Bukti potong tersimpan
☐ Bukti transaksi tersedia
☐ Supporting document tersedia
☐ Audit trail dapat ditelusuri
Bagaimana Mencegah Kesalahan e-Bupot Berulang?
Perusahaan sering melakukan satu kesalahan ketika menemukan masalah.
Mereka langsung mencari:
“Siapa yang melakukan kesalahan?”
Padahal pertanyaan yang lebih penting adalah:
“Mengapa sistem kerja kita memungkinkan kesalahan ini terjadi?”
Misalnya:
Kesalahan:
Tax Staff salah memilih jenis transaksi.
Pertanyaan berikutnya:
Apakah ada SOP?
Apakah ada checklist?
Apakah ada reviewer?
Apakah staff sudah mendapatkan training?
Apakah transaksi memiliki mapping yang jelas?
Dengan pendekatan tersebut, perusahaan tidak hanya memperbaiki satu kesalahan.
Tetapi memperbaiki sistem kerja.
Dari “Human Error” Menjadi “Process Improvement”
Misalnya terjadi:
Vendor salah data
Jangan hanya:
“Tax harus lebih teliti.”
Tetapi:
Master Data
→ Validation
→ Approval
→ Tax
Begitu pula jika:
e-Bupot salah nominal
Jangan hanya:
“Staff harus lebih hati-hati.”
Tetapi:
Invoice
→ Tax Data
→ e-Bupot
→ Reconciliation
→ Review
Dengan demikian, kontrol menjadi bagian dari proses.
Mengapa Training Coretax Penting untuk e-Bupot?
Studi kasus di atas menunjukkan bahwa kemampuan menggunakan Coretax memiliki beberapa tingkatan.
Level 1 — Bisa Login
User dapat masuk ke sistem.
Level 2 — Bisa Input
User dapat memasukkan data.
Level 3 — Bisa Memproses
User dapat menyelesaikan administrasi.
Level 4 — Bisa Menganalisis
User memahami dampak transaksi.
Level 5 — Bisa Mengontrol
User memahami workflow, rekonsiliasi, dan risiko.
Bagi perusahaan, Level 4 dan Level 5 menjadi semakin penting.
Karena user tidak hanya dituntut:
“Bisa menggunakan Coretax.”
Tetapi:
“Bisa memastikan administrasi pajak perusahaan berjalan benar.”
Contoh Studi Kasus untuk Training Coretax e-Bupot
Dalam pelatihan, peserta dapat diberikan simulasi:
PT ABC melakukan pembayaran jasa kepada vendor sebesar Rp500 juta. Setelah bukti potong dibuat, vendor menginformasikan bahwa data identitasnya berubah. Pada saat yang sama, Accounting menemukan bahwa nilai invoice yang digunakan Tax bukan merupakan invoice final.
Peserta kemudian diminta menjawab:
- Apa masalahnya?
- Data mana yang harus diperiksa?
- Apakah ada dampak terhadap bukti potong?
- Siapa yang perlu dilibatkan?
- Bagaimana workflow koreksinya?
- Bagaimana mencegah masalah yang sama terulang?
Dengan metode seperti ini, peserta tidak sekadar belajar:
“Klik menu A → pilih B → submit.”
Mereka belajar:
Analyze → Decide → Process → Review → Control.
NEMA Academy: Training Coretax Berbasis Studi Kasus
Implementasi Coretax membutuhkan lebih dari sekadar kemampuan teknis menggunakan aplikasi.
Tim perusahaan juga perlu memahami:
- workflow;
- pembagian tanggung jawab;
- tax treatment;
- validasi;
- rekonsiliasi;
- internal control;
- penyelesaian masalah.
Karena itu, Training Coretax NEMA Academy dapat dikembangkan dengan pendekatan praktik dan studi kasus yang relevan dengan kebutuhan perusahaan.
Peserta dapat berasal dari:
Tax
Finance
Accounting
Admin
Supervisor
Manager
Materi e-Bupot dapat diarahkan pada skenario yang dekat dengan pekerjaan sehari-hari, seperti:
- kesalahan data vendor;
- salah klasifikasi transaksi;
- perbedaan invoice dan bukti potong;
- transaksi belum dibuatkan bukti potong;
- duplikasi;
- revisi transaksi;
- rekonsiliasi;
- pembagian role;
- internal control.
Dengan demikian, training tidak berhenti pada kemampuan menggunakan Coretax, tetapi membantu peserta memahami bagaimana Coretax e-Bupot menjadi bagian dari proses bisnis dan pengendalian administrasi pajak perusahaan.
Kesimpulan
Studi kasus Coretax e-Bupot menunjukkan bahwa kesalahan bukti potong tidak selalu disebabkan oleh kesalahan saat melakukan input.
Masalah dapat berasal dari:
Data
↓
Tax Knowledge
↓
Workflow
↓
System
↓
Review
↓
Reconciliation
Jika perusahaan hanya memperbaiki kesalahan pada tahap terakhir, masalah yang sama berpotensi muncul kembali.
Karena itu, perusahaan perlu membangun proses:
Data → Assessment → e-Bupot → Validation → Review → Reconciliation → Monitoring
dan memastikan setiap fungsi memahami perannya.
Pada akhirnya, keberhasilan administrasi Coretax e-Bupot bukan hanya tentang:
“Apakah tim bisa membuat bukti potong?”
Tetapi:
“Apakah perusahaan mampu memastikan seluruh transaksi yang relevan diproses secara tepat, konsisten, terkontrol, dan dapat ditelusuri?”
Di sinilah kesiapan SDM menjadi penting.
Training Coretax berbasis praktik dan studi kasus dapat membantu tim memahami bukan hanya cara menggunakan sistem, tetapi juga cara menghadapi kondisi nyata yang mungkin muncul dalam pekerjaan.
NEMA Academy siap membantu perusahaan mempersiapkan tim Tax, Finance, Accounting, Supervisor, dan Management agar lebih siap menghadapi Coretax dan perubahan administrasi perpajakan.
Butuh training perpajakan untuk tim Anda?
NEMA Academy merancang in-house training dan pendampingan yang disesuaikan dengan kebutuhan organisasi Anda. Konsultasikan kebutuhan tim Anda langsung dengan kami.