Model data faktur GST: field minimum untuk HSN dan pesanan

Apa yang biasanya salah dengan faktur GST

Sebagian besar masalah faktur GST bukanlah masalah "pajak kompleks". Mereka adalah masalah data yang hilang atau tidak konsisten. Audit gagal ketika faktur tidak dapat dihubungkan dengan jelas ke apa yang dijual, kepada siapa, di mana disuplai, dan bagaimana pajak dihitung.

Pemicu umum adalah HSN yang tidak ada, usang, atau diterapkan di tingkat yang salah. Tim mungkin menyimpan HSN pada produk, tetapi baris faktur dibuat dari nama SKU atau varian yang berbeda, sehingga HSN tidak pernah masuk ke dokumen akhir. Masalah sering lain adalah pemisahan pajak yang salah: mengenakan IGST ketika seharusnya CGST dan SGST (atau sebaliknya) karena "tempat penyerahan" ditebak dari alamat pengiriman tanpa menyimpan kode negara bagian yang digunakan untuk keputusan itu.

Tim keuangan langsung merasakan ini. Rekonsiliasi menjadi pekerjaan pembersihan harian: total faktur tidak cocok dengan pesanan, pesanan tidak cocok dengan penyelesaian gateway pembayaran, dan pengembalian menjadi rangkaian catatan manual. Bahkan selisih pembulatan kecil di antar baris bisa menciptakan ketidakcocokan antara PDF faktur, laporan GST, dan buku besar.

Berikut pola yang paling sering menyebabkan masalah ketidakcocokan:

• Produk dan baris faktur tidak berbagi HSN, tarif GST, dan field nilai kena pajak yang sama.
• Pajak dihitung di lebih dari satu tempat (keranjang vs faktur) dan menghasilkan selisih.
• Total disimpan hanya sebagai "grand total" tanpa rincian nilai kena pajak dan setiap komponen pajak.
• Penomoran faktur dapat diedit atau terduplikasi di beberapa seri.
• Pengembalian dicatat sebagai pesanan negatif daripada nota kredit yang benar.

Tujuan model data faktur GST sederhana: simpan satu set minimum field order, produk, pihak, pajak, faktur, dan nota kredit sehingga setiap angka dapat direproduksi dan dijelaskan nanti. Jaga tetap kecil, namun jangan buang field penting secara hukum yang menentukan jenis pajak, tarif, dan pelaporan.

Set rekaman terkecil yang Anda butuhkan

Jika Anda ingin faktur GST mudah dibuat dan mudah direkonsiliasi nanti, mulailah dengan sejumlah objek kecil dan buat masing-masing melakukan satu tugas. Model data faktur GST yang bersih lebih tentang menjaga fakta tetap stabil dari waktu ke waktu daripada memiliki banyak tabel.

Berikut adalah rekaman inti yang biasanya dibutuhkan tim pada hari pertama:

• Customer: siapa yang membeli (nama, telepon/email, GSTIN jika B2B)
• Address: pengiriman dan penagihan, plus sinyal negara dan tempat penyerahan
• Product (atau Service): apa yang dijual, dengan satuan, harga dasar, dan HSN/SAC default
• Order: kejadian komersial (keranjang, diskon, biaya pengiriman, status)
• Payment: bagaimana uang bergerak (referensi gateway, metode, jumlah yang ditangkap, tanggal)

Sebuah Invoice harus terpisah dari Order. Pesanan bisa berubah (alamat diedit, item dibatalkan, pemenuhan parsial). Faktur tidak boleh berubah. Mereka perlu penomoran stabil, tanggal, dan total yang tidak pernah "menggelincir" karena seseorang memperbarui pesanan nanti.

Jangkar untuk akurasi pajak adalah Line Items. Setiap baris pesanan (dan kemudian setiap baris faktur) harus memuat kuantitas tepat, harga satuan, diskon, dan rincian pajak untuk item itu. Di situlah HSN/SAC dan tarif GST benar-benar diterapkan.

Satu detail yang menyelamatkan tim keuangan: simpan snapshot. Ketika Anda menghasilkan faktur, salin deskripsi produk, HSN/SAC, tarif pajak, dan harga ke baris faktur. Jangan bergantung pada master produk saat ini, karena tarif dan nama berubah.

Opsional tapi sering berguna ditambahkan sejak awal adalah Returns, Refunds, dan Credit Notes sebagai rekaman terpisah. Contoh: jika pelanggan mengembalikan satu item dari pesanan dua item, Anda ingin nota kredit yang merujuk baris faktur asli, sementara rekaman pengembalian dana merujuk transaksi gateway. Menjaga ini sebagai objek eksplisit mencegah "perbaikan manual" akhir bulan pada register GST.

Jika Anda membangun ini di Koder.ai, perlakukan setiap objek sebagai layar sederhana terlebih dahulu (buat, lihat, edit), lalu tambahkan pembuatan faktur hanya setelah snapshot dan field tingkat-baris ada.

HSN dan SAC: di mana mereka masuk dalam model

HSN (untuk barang) dan SAC (untuk jasa) bukan detail "hanya-faktur". Mereka dimulai pada definisi produk atau layanan, lalu disalin ke setiap baris faktur saat Anda menerbitkan faktur. Ini menjaga keranjang campuran tetap benar dan memudahkan audit karena setiap baris berdiri sendiri.

Model data minimum yang praktis adalah:

• Product: id, name, SKU, unit (UOM), base_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code
• InvoiceLine: id, invoice_id, product_id (opsional untuk baris manual), description, unit, qty, unit_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code

Menempatkan HSN/SAC pada Product membantu tim admin memeliharanya di satu tempat. Menyalinnya ke InvoiceLine membuat faktur lampau stabil. Bahkan jika produk berubah nanti, faktur masih menunjukkan apa yang benar pada saat penjualan. Inilah inti model data faktur GST yang tidak rusak saat rekonsiliasi.

Untuk penyimpanan HSN, jaga sederhana: kode diperlukan, deskripsi opsional, dan effective_from date opsional jika Anda ingin riwayat perubahan. Kebanyakan tim tidak membutuhkan deskripsi di setiap baris, tetapi ini membantu saat tim keuangan memeriksa pengecualian.

Keranjang campuran adalah normal: satu faktur dapat memiliki beberapa baris dan karena itu beberapa kode HSN/SAC. Jangan paksa satu kode per faktur. Total dijumlahkan di tingkat faktur, sementara klasifikasi tetap di tingkat baris.

Manajemen perubahan adalah tempat orang sering mengalami masalah. Gunakan serangkaian aturan kecil:

• Jangan pernah menimpa HSN/SAC pada baris faktur yang telah diterbitkan.
• Jika HSN/SAC produk berubah, perbarui Product hanya untuk pesanan di masa depan.
• Jika Anda melacak riwayat, tambahkan catatan effective_from baru daripada mengedit yang lama.

Untuk layar admin, Anda hanya butuh satu tempat untuk mengedit field pajak Product, plus tampilan read-only pada baris faktur untuk mengonfirmasi apa yang tercapture saat faktur dibuat. Jika Anda membangun layar ini dengan cepat, alat seperti Koder.ai bisa menghasilkan halaman CRUD dasar dan tabel data dari model ini dengan upaya minimal.

Detail pihak: GSTIN, alamat, dan tempat penyerahan

Model data faktur GST sering gagal karena detail pihak. Jika identitas pembeli atau penjual sedikit saja keliru, faktur bisa sah di atas kertas tetapi menyulitkan pada pelaporan dan rekonsiliasi.

Mulailah dengan memperlakukan "penjual", "pembeli", dan "ship-to" sebagai pihak terpisah, bahkan saat mereka orang yang sama. Ini mencegah solusi sementara saat pelanggan menambah alamat pengiriman berbeda atau ketika Anda menjual dari lebih dari satu registrasi GST.

Field minimum yang harus disimpan (pembeli dan penjual)

Buat fieldnya membosankan dan eksplisit. Ini yang biasanya diperlukan di faktur dan laporan:

• Nama legal (sesuai yang harus muncul di faktur)
• Nama dagang (opsional, tapi berguna)
• GSTIN (penjual wajib; pembeli boleh nullable)
• Telepon/email (tidak selalu wajib, tapi membantu untuk support)
• Baris alamat, kota, negara bagian, negara, PIN/kode pos

Simpan negara bagian sebagai nama yang mudah dibaca dan juga kode negara bagian, karena pelaporan dan aturan tempat penyerahan sering bergantung pada kode.

Penagihan vs pengiriman dan tempat penyerahan

Tangkap alamat penagihan dan pengiriman pada pesanan, bukan hanya pada profil pelanggan. Profil berubah; faktur tidak boleh.

Tempat penyerahan harus disimpan sebagai kode negara bagian spesifik pada faktur (disalin dari pesanan saat pembuatan faktur). Jangan "menghitung ulang" nanti. Jika aturan Anda adalah "negara pengiriman", simpan hasil itu, plus negara bagian yang digunakan untuk memutuskannya. Ini memudahkan audit dan sengketa.

B2B vs B2C: kapan GSTIN wajib

Untuk B2B, GSTIN pembeli biasanya diwajibkan dan harus divalidasi untuk panjang dan format saat diinput. Untuk B2C, GSTIN dapat dibiarkan kosong, tetapi Anda tetap membutuhkan alamat lengkap dan negara bagian untuk menentukan apakah CGST/SGST atau IGST yang berlaku.

Aturan sederhana yang bekerja di banyak sistem: jika GSTIN pembeli ada, perlakukan sebagai B2B; jika tidak, perlakukan sebagai B2C. Jika perlu pengecualian, simpan field customer_type eksplisit.

Penjual multi-entitas (beberapa GSTIN)

Jika Anda memiliki cabang atau unit bisnis dengan registrasi GST berbeda, modelkan “Seller Entity” sebagai record sendiri dengan GSTIN dan alamatnya. Setiap pesanan harus merujuk tepat satu seller entity, dan setiap faktur harus menyalin detail itu sehingga faktur historis tetap akurat meski alamat penjual berubah nanti.

Alat seperti Koder.ai dapat menghasilkan form admin untuk record ini dengan cepat, tapi inti adalah struktur: entitas penjual terpisah, snapshot saat pesanan, dan kode negara bagian tempat penyerahan yang eksplisit.

Field perhitungan pajak yang harus Anda simpan

Pemisahan yang paling umum sederhana: jika tempat penyerahan berada di negara bagian yang sama dengan pemasok, pajak adalah CGST + SGST. Jika berbeda negara bagian, pajak adalah IGST. Sistem Anda tidak boleh "menghitung ulang nanti dari total" karena perbedaan kecil (pembulatan, diskon, pengiriman) justru yang menyebabkan ketidakcocokan.

Setidaknya, simpan angka pajak di tingkat baris faktur, bukan hanya header faktur. Dengan begitu Anda bisa menjelaskan setiap rupiah di faktur dan mencocokkannya kembali ke produk, HSN, dan pendapatan.

Minimum praktis per baris faktur dalam model data faktur GST Anda terlihat seperti ini:

• taxable_value (setelah alokasi diskon tingkat baris)
• gst_rate_percent
• cgst_rate_percent, sgst_rate_percent, igst_rate_percent (simpan pemisahan yang digunakan)
• cgst_amount, sgst_amount, igst_amount (simpan jumlah yang dihitung)
• line_total (taxable_value + jumlah pajak)

Diskon adalah tempat sistem sering berantakan. Putuskan satu aturan dan simpan dengan jelas. Jika diskon mengurangi harga sebelum pajak (typical untuk diskon item dan kupon), simpan jumlah bruto asli, jumlah diskon, dan taxable value yang dihasilkan. Jika Anda memiliki kupon tingkat pesanan, alokasikan ke setiap baris (biasanya proporsional terhadap taxable value pra-diskon masing-masing baris) dan simpan alokasi diskon tiap baris sehingga matematika pajak bisa dijelaskan.

Pembulatan harus konsisten dan dicatat. Pilih apakah Anda membulatkan di tingkat baris atau hanya di tingkat faktur, lalu simpan hasil yang Anda cetak. Banyak tim menghitung pajak per baris, membulatkan ke 2 desimal, menjumlahkan, lalu menerapkan field invoice_rounding_adjustment akhir untuk mencapai jumlah yang tepat dibayar.

Pengiriman dan penanganan tidak boleh menjadi biaya tersembunyi. Perlakukan mereka sebagai baris faktur terpisah dengan HSN/kode layanan dan aturan tarif pajak sendiri. Misalnya, pesanan dengan dua produk dan biaya pengiriman menjadi tiga baris, masing-masing dengan taxable value dan jumlah komponen pajak yang tersimpan, sehingga rekonsiliasi keuangan jauh lebih mudah.

Data dokumen faktur: penomoran, tanggal, total, status

Setelah pajak dihitung, faktur masih membutuhkan field "dokumen" yang membuatnya sah, dapat diaudit, dan mudah direkonsiliasi nanti. Dalam model data faktur GST, perlakukan header faktur seperti catatan hukum: harus stabil meski data produk atau pelanggan berubah di masa depan.

Mulailah dengan dasar header: nomor faktur, tanggal penerbitan (tanggal di faktur), tipe faktur (tax invoice, export, B2B, B2C, dll.), dan mata uang. Meski Anda sebagian besar menagih dalam INR, menyimpan mata uang menghindari kasus tepi untuk ekspor atau marketplace multi-mata uang.

Penomoran adalah tempat tim sering terbakar. Simpan seri atau prefix (mis. "FY25-INV-"), simpan tahun fiskal, dan wajibkan keunikan di tingkat database. Juga simpan kontrol "nomor berikutnya" per seri di admin agar dua admin tidak menerbitkan nomor yang sama bersamaan.

Total harus disimpan secara eksplisit, bukan hanya diturunkan. Simpan subtotal (nilai kena pajak), total pajak, grand total, dan jumlah pembulatan terpisah. Jika Anda menghitung ulang nanti dari baris, perubahan aturan kecil dapat membuat faktur lama tidak cocok dengan laporan yang diajukan.

Status harus mencerminkan siklus hidup nyata dan mengunci record saat diperlukan:

• Draft (dapat diedit)
• Issued (nomor ditetapkan, PDF dihasilkan)
• Cancelled (disimpan untuk audit, tidak dihapus)
• Refunded (pembayaran dibalik, mungkin memerlukan nota kredit)
• Credit noted (nota kredit terkait diterbitkan)

Terakhir, simpan metadata artefak yang dihasilkan: versi template PDF, timestamp pembuatan, dan identifier file. Hash opsional, tetapi berguna jika Anda perlu membuktikan PDF tidak diubah.

Contoh: jika agen support menghasilkan ulang PDF setelah pembaruan template, total dan nomor faktur harus tetap identik, tetapi versi template yang tersimpan menjelaskan mengapa tampilan PDF berbeda.

Layar admin untuk produk, pajak, dan detail pelanggan

Jika Anda menginginkan faktur GST yang bersih, jangan mulai dari layar faktur. Mulailah dengan halaman admin yang mengisi faktur. Model data faktur GST tetap kecil ketika input-input ini dikontrol dan konsisten.

Master produk (SKU ke HSN/SAC)

Master produk adalah tempat sebagian besar ketidakcocokan masa depan dimulai, jadi buatlah ketat. Setiap SKU harus memiliki tepat satu HSN default (atau SAC untuk layanan), plus tarif GST default dan pengecualian yang berlaku hanya untuk tanggal tertentu.

Layar produk praktis biasanya perlu:

• SKU dan nama produk (sesuai yang ingin dicetak)
• Kode HSN/SAC, tarif GST, dan kategori pajak (jika digunakan)
• Active from/to dates (agar perubahan tidak menulis ulang faktur lama)
• Override harga (untuk MRP khusus atau harga spesifik kanal)
• Status (aktif/nonaktif) dengan alasan jelas untuk nonaktifkan

Pengaturan pajak (tarif dan input intra vs inter-state)

Hindari UI "kalkulator". Sebaliknya, simpan input yang bisa diterapkan sistem Anda secara konsisten: tabel tarif, aturan tempat penyerahan yang Anda ikuti, dan bagaimana Anda memutuskan intra-state vs inter-state (biasanya dengan membandingkan negara bagian pemasok dan negara pengiriman).

Fokus layar pajak pada: tarif pajak menurut kategori/grup HSN, tanggal efektif, dan apa yang harus terjadi ketika pembeli menyediakan GSTIN yang valid vs tidak.

Profil pelanggan dan perusahaan (siapa yang ada di faktur)

Layar pelanggan harus menangkap GSTIN dan status validasinya, plus alamat penagihan dan pengiriman default. Jangan biarkan pengguna mengetik negara bagian bebas; gunakan daftar terkontrol jadi "KA" dan "Karnataka" tidak menjadi dua nilai berbeda.

Layar profil perusahaan sama pentingnya: nama legal, GSTIN, alamat terdaftar, dan pengaturan seri faktur (prefix, nomor berikutnya, dan batas tahun fiskal). Kunci ini dengan hak akses karena perubahan memengaruhi setiap dokumen masa depan.

Dasar log audit (kepercayaan dan jejak)

Anda tidak butuh sistem kompleks, tapi butuh jejak. Log siapa yang mengubah HSN/SAC, tarif GST, pengaturan seri faktur, atau GSTIN perusahaan, beserta nilai lama, nilai baru, timestamp, dan alasan.

Jika membangun layar ini di alat seperti Koder.ai, anggap logging audit dan tanggal efektif sebagai field kelas satu sejak hari pertama. Mereka murah ditambahkan awal dan menghemat jam saat peninjauan keuangan nanti.

Langkah demi langkah: dari pesanan ke faktur yang patuh

Faktur yang patuh lebih tentang membekukan fakta yang tepat pada waktu yang tepat daripada format yang mewah. Jika Anda merancang model data faktur GST di sekitar alur ini, pekerjaan keuangan menjadi pencocokan sederhana, bukan investigasi mingguan.

1) Bekukan apa yang dibeli pelanggan

Sebelum menghitung pajak, kunci snapshot pesanan: item, kuantitas, harga satuan, diskon, biaya pengiriman/penanganan, GSTIN pelanggan (jika ada), alamat penagihan dan pengiriman, dan sinyal tempat penyerahan. Snapshot tidak boleh berubah meski harga produk atau pemetaan HSN berubah nanti.

2) Ubah snapshot menjadi baris faktur (dengan atribut pajak yang disalin)

Hitung pajak dan buat baris faktur dari snapshot. Setiap baris faktur harus menyalin HSN/SAC, tarif pajak, taxable value, dan jumlah pajak yang digunakan saat itu, bukan mencari nilai secara live nanti.

3) Terbitkan faktur dan buat tidak dapat diubah

Tetapkan nomor faktur dan tanggal terbit, lalu tandai faktur sebagai issued. Mulai saat ini, blokir edit pada harga, tarif pajak, kode HSN, dan alamat pada record faktur. Jika perlu mengizinkan apa pun, batasi pada catatan non-finansial dan tag internal.

4) Hasilkan dokumen akhir dan simpan total

Hasilkan PDF/tampilan cetak dari faktur yang diterbitkan, lalu simpan total final yang akan Anda laporkan: total kena pajak, total CGST/SGST/IGST, pembulatan, dan grand total. Jika ingin keamanan ekstra, simpan versi dokumen atau checksum agar Anda dapat membuktikan tampilan cetak cocok dengan angka yang tersimpan.

5) Tangani perubahan secara legal

Setelah terbit, perubahan harus mengikuti aturan, bukan edit:

• Pelanggan minta koreksi harga: terbitkan nota kredit (atau debit note) yang merujuk faktur asli.
• Pesanan dibatalkan setelah terbit: batalkan faktur jika diizinkan, jika tidak terbitkan nota kredit.
• Pelanggan memperbarui alamat setelah terbit: jangan menulis ulang faktur; koreksi lewat dokumen yang tepat dan simpan jejak audit.
• Pengembalian parsial: nota kredit hanya untuk baris/jumlah yang dikembalikan.
• Pengiriman pengganti: pesanan/faktur baru, bukan edit diam-diam.

Jika Anda membangun alur ini ke layar admin Anda (mode perencanaan seperti Koder.ai membantu memetakan langkah sebelum membangun), tim Anda dapat menghasilkan faktur dengan cepat tanpa merusak rekonsiliasi nanti.

Buat rekonsiliasi mudah: pembayaran, pengembalian, dan register

Rekonsiliasi berantakan ketika pembayaran diperlakukan sebagai flag "lunas/tidak" di pesanan. Simpan pembayaran dan pengembalian sebagai record terpisah yang menunjuk ke pesanan dan faktur, sehingga tim keuangan dapat mencocokkan penyelesaian bank tanpa menulis ulang sejarah.

Rekaman pembayaran dan pengembalian terpisah (jangan edit faktur)

Faktur yang patuh harus tetap stabil setelah diterbitkan. Jika pelanggan membayar bertahap, atau Anda mengembalikan dana nanti, catat pergerakan itu sebagai entri pembayaran atau pengembalian, bukan sebagai perubahan total faktur.

Field minimum yang biasanya mempermudah rekonsiliasi:

• Payment: payment_id, order_id, invoice_id, method, gateway_name, gateway_payment_id, amount, currency, authorized_at, captured_at, settlement_date, status
• Settlement (opsional tapi membantu): settlement_id, gateway_payout_id, settlement_date, gross_amount, fees, net_amount
• Refund: refund_id, order_id, invoice_id, payment_id, credit_note_id (jika diterbitkan), gateway_refund_id, amount, reason, refunded_at, status
• Kunci rekonsiliasi yang tidak boleh Anda gunakan ulang: order_id, invoice_id, payment_id, refund_id, credit_note_id

Jika pelanggan mengembalikan satu item, jangan "kurangi faktur." Terbitkan nota kredit dan link ke faktur asli. Register faktur tetap bersih, dan pengembalian dana terikat ke nota kredit.

Tampilan keuangan dan ekspor yang menghemat jam

Berikan tim keuangan satu layar yang menjawab: apa yang diterbitkan, apa yang dibayar, apa yang masih terbuka, dan apa yang dibalik. Sertakan ageing (0-7, 8-30, 31-60, 60+ hari) dan drill-down ke pembayaran serta entri pengembalian terkait.

Ekspor yang biasanya dibutuhkan tim setiap bulan:

• Register faktur (diterbitkan, dibatalkan, diberi nota kredit)
• Ringkasan pajak menurut tarif dan HSN/SAC (mendukung model data faktur GST Anda)
• Rekonsiliasi Pembayaran vs Faktur (invoice_id, total pembayaran, saldo)
• Register pengembalian dan nota kredit
• Laporan penyelesaian gateway (payout_id ke pemetaan invoice/payment)

Contoh: sebuah pesanan senilai Rs 10,000, dibayar Rs 6,000 hari ini dan Rs 4,000 minggu depan. Faktur tetap Rs 10,000. Tampilan keuangan menunjukkan saldo Rs 4,000 hingga penyelesaian kedua tiba, lalu menandainya lunas tanpa mengubah dokumen yang diterbitkan.

Perangkap umum yang menyebabkan masalah kepatuhan dan ketidakcocokan

Sebagian besar masalah faktur GST bukan soal logika pajak. Mereka soal pencatatan: angka di PDF tidak cocok dengan yang diekspor oleh tim keuangan, atau faktur tidak bisa dijelaskan beberapa bulan kemudian.

Perangkap pertama adalah menghitung GST hanya saat dilihat. Jika Anda menghitung CGST/SGST/IGST setiap kali seseorang membuka faktur, lama-lama hasilnya berbeda setelah perubahan tarif, aturan pembulatan, atau perbaikan bug. Simpan rincian pajak yang dihitung saat faktur diterbitkan, meski Anda juga menyimpan inputnya.

Perangkap kedua adalah mengizinkan edit pada faktur yang sudah diterbitkan. Begitu faktur final, perubahan harus lewat nota kredit atau alur penggantian dengan jejak audit. Kalau tidak, Anda akan melihat argumen "mengapa PDF pelanggan berbeda dengan buku?"

Berikut pola ketidakcocokan yang paling sering muncul dalam model data faktur GST:

• Tempat penyerahan hilang atau kode negara bagian salah, sehingga IGST diterapkan padahal seharusnya CGST+SGST (atau sebaliknya).
• HSN/SAC produk atau tarif pajak diperbarui, dan pesanan lama dihitung ulang memakai nilai baru.
• Pajak disimpan, tetapi aturan pembulatan berbeda antara UI, pembangkitan PDF, dan ekspor CSV.
• Diskon diterapkan setelah pajak di satu tempat dan sebelum pajak di tempat lain.
• Pengembalian dicatat sebagai baris negatif tanpa tautan jelas ke faktur asli.

Contoh cepat: Anda menjual ke pelanggan di Karnataka, tetapi alamat pengiriman di Maharashtra. Jika sistem memilih negara bagian penagihan untuk tempat penyerahan secara keliru, Anda mungkin mengenakan CGST+SGST bukannya IGST. Jika Anda juga menghitung ulang pajak secara langsung, kesalahan itu bisa "memperbaiki diri" nanti, meninggalkan tim keuangan dengan angka yang tidak cocok dengan dokumen yang diterbitkan.

Saat membangun layar admin (apakah kustom atau via platform seperti Koder.ai), tambahkan pengaman kecil: kunci faktur yang diterbitkan, tampilkan input tempat-penyerahan di samping tipe pajak yang dihitung, dan simpan snapshot immutable dari HSN, tarif, dan pembulatan yang dipakai saat penerbitan.

Daftar periksa cepat dan langkah berikutnya

Sebelum Anda mengirim faktur ke pelanggan atau menandainya sebagai "diterbitkan", jalankan serangkaian pemeriksaan cepat. Di sinilah kebanyakan kesalahan kecil berubah menjadi masalah rekonsiliasi besar nanti. Jika Anda membangun model data faktur GST, patut menanamkan pemeriksaan ini baik ke aturan validasi maupun UI admin.

Pemeriksaan per-faktur (sebelum menerbitkan)

• HSN/SAC ada di setiap baris dan cocok dengan produk atau layanan yang sebenarnya Anda jual.
• Aturan GSTIN diterapkan dengan benar (B2B vs B2C), dan detail penagihan serta pengiriman tidak saling bertentangan.
• Tempat penyerahan disimpan dan pemisahan pajak masuk akal (CGST/SGST vs IGST).
• Total tepat: nilai kena pajak, setiap komponen pajak, pembulatan, dan grand total.
• Setelah diterbitkan, faktur dikunci (tidak ada edit diam-diam). Perbaikan dilakukan lewat nota kredit atau alur pembatalan, bukan menulis ulang sejarah.

Contoh sederhana: pelanggan memperbarui alamat pengiriman setelah pembayaran, dan negara bagian berubah. Jika Anda menerbitkan ulang nomor faktur yang sama dengan pajak baru, register dan catatan pembayaran Anda tidak akan cocok. Pendekatan yang lebih aman adalah menjaga faktur asli immutable dan membuat dokumen penyesuaian.

Pemeriksaan data + alur kerja (untuk menjaga kebersihan keuangan)

• Penomoran faktur unik, berurutan sesuai kebijakan, dan dihasilkan hanya saat "issue".
• Simpan jumlah pajak yang dihitung, bukan hanya tarif, sehingga laporan tetap stabil meski tarif berubah nanti.
• Langkah status jelas: draft -> issued -> cancelled (dan dokumen nota kredit terpisah).
• Laporan direkonsiliasi per periode: total register faktur harus sesuai dengan pembayaran yang ditangkap, pengembalian yang diproses, dan piutang tersisa.
• Field audit selalu ada: created by, issued at, dan catatan alasan untuk pembatalan atau nota kredit.

Langkah berikutnya: implementasikan layar dan validasi dulu, lalu iterasi. Di Koder.ai, mulai dengan Planning Mode untuk menggambar record dan layar admin (produk dengan pemetaan HSN/SAC, detail pelanggan/GSTIN, aturan pajak, dan faktur). Hasilkan aplikasi, uji beberapa pesanan nyata end-to-end, lalu gunakan snapshot dan rollback untuk menyempurnakan alur dengan aman. Saat perlu kustomisasi lebih dalam atau peninjauan, ekspor kode sumber dan terus kembangkan sesuai proses biasa Anda.