Kewajiban Pelaporan Pajak MTD HMRC bagi Pelaku Usaha
Empat kali setahun, pelaku usaha perorangan dan pemilik properti yang masuk skema Making Tax Digital (MTD) untuk Pajak Penghasilan di Inggris harus mengirim ringkasan pendapatan dan biaya kepada HM Revenue and Customs (HMRC). Tenggat pertama tahun pajak 2026-2027, 7 Agustus, telah lewat. Tenggat kedua jatuh pada 7 November. Di balik kewajiban administratif itu, proses teknisnya tampak sederhana: satu panggilan API dari perangkat lunak akuntansi ke sistem HMRC. Namun satu panggilan itu menentukan apakah laporan diterima, ditolak, menggantikan data sebelumnya, atau bahkan menghapus angka kuartal terdahulu karena keliru memahami model kumulatif. Solomon Amos, pendiri TapTax sekaligus pembangun integrasi MTD aplikasi tersebut, merangkum alur teknisnya dalam panduan berbasis Node dan TypeScript. Ia menekankan satu prinsip utama: pembaruan kuartalan bukan SPT final, melainkan total berjalan sejak awal tahun pajak sampai akhir periode pelaporan.
Penyiapan Lingkungan Sandbox dan Izin Akses API
Sebelum pelaporan dilakukan, pengembang harus menyiapkan fondasi yang sama untuk setiap integrasi MTD. Aplikasi sandbox perlu didaftarkan di HMRC Developer Hub, lalu berlangganan empat API: Business Details, Obligations, Self Employment Business, dan Individual Calculations. Jika satu API belum diaktifkan, sistem dapat mengembalikan 403 Forbidden, yang kerap disangka masalah otorisasi. Setelah itu, pengembang membuat pengguna uji melalui Create Test User API untuk memperoleh National Insurance number dan kredensial Government Gateway. Token akses diperoleh lewat alur OAuth 2.0 dengan cakupan read:self-assessment dan write:self-assessment. Setiap permintaan juga wajib membawa fraud prevention headers, yang formatnya bergantung pada cara aplikasi terhubung. Kesalahan kecil pun berdampak langsung: header Accept harus memuat versi API yang benar, sebab versi keliru menghasilkan 406 Not Acceptable. Bahkan Content-Type tidak boleh asal dikirim pada permintaan GET tanpa badan, karena edge HMRC dapat menolaknya.
Alur pelaporan dimulai dari pencarian businessId. Identitas ini diambil melalui Business Details API berdasarkan National Insurance number. Seorang pedagang tunggal yang juga menyewakan properti dapat memiliki lebih dari satu sumber penghasilan, sehingga setiap usaha punya businessId berbeda. HMRC menyarankan ID itu disimpan, bukan dicari ulang setiap kali, karena daftar bisnis jarang berubah kecuali pelanggan menambah atau menghentikan usaha. Setelah businessId diketahui, perangkat lunak meminta Obligations API untuk membaca periode mana yang masih terbuka. Respons API mengelompokkan kewajiban berdasarkan bisnis, lalu menaruh detail periode di dalamnya: tanggal mulai, tanggal akhir, tanggal jatuh tempo, serta status. Dalam praktik antarmuka, data itu biasanya diratakan menjadi satu baris per kewajiban. Periode terbuka dengan jatuh tempo paling awal dipilih. Amos mengingatkan, pengembang tidak perlu menghitung sendiri tenggat. Tanggal jatuh tempo harus dibaca dari respons HMRC, karena otoritas pajak dapat mengubah jadwal, sedangkan API menjadi sumber kebenaran.
Struktur Payload dan Pelaporan Data Kumulatif
Bagian paling krusial terletak pada pembuatan ringkasan kumulatif. Untuk pembaruan kuartal kedua 2026-2027, misalnya, periode berjalan dari 6 April sampai 5 Oktober, bukan hanya tiga bulan terakhir. Payload yang dikirim ke Self Employment Business API memuat periodDates, periodIncome, periodExpenses, serta bila diperlukan periodDisallowableExpenses. Pendapatan meliputi turnover, pendapatan lain, dan pajak yang telah dipotong dari penghasilan perdagangan. Biaya dapat dilaporkan dalam satu angka consolidatedExpenses atau secara terperinci melalui kategori seperti costOfGoods, carVanTravelExpenses, adminCosts, dan professionalFees. Keduanya tidak boleh dicampur. Jika consolidatedExpenses dikirim bersama item biaya terperinci, HMRC mengembalikan RULE_BOTH_EXPENSES_SUPPLIED. Aturan ambang juga penting: biaya konsolidasi hanya boleh dipakai jika omzet tahunan di bawah 90.000 pound sterling. Karena pembaruan bersifat kumulatif, pengecekan praktis dilakukan terhadap omzet tahun berjalan pada setiap pengiriman. Semua angka juga harus dibulatkan maksimal dua desimal.
Risiko Penimpaan Data pada Metode PUT Kumulatif
Pengiriman dilakukan melalui metode PUT ke endpoint kumulatif self-employment, dengan tahun pajak dalam format YYYY-YY pada path. Tanggal periode tetap berada dalam badan permintaan. Keberhasilan ditandai 204 No Content, tanpa nomor tanda terima. Karena itu, aplikasi wajib menyimpan catatan audit sendiri: apa yang dikirim, kapan dikirim, dan status yang dikembalikan HMRC. Sifat PUT membuat panggilan yang sama dipakai untuk membuat sekaligus mengubah. Di sinilah risiko besar muncul. Setiap pengiriman menggantikan data tahun berjalan yang sebelumnya disimpan HMRC. Jika formulir dibuka kosong lalu pengguna hanya memasukkan angka kuartal terbaru, aplikasi dapat menimpa total kumulatif dan menghapus angka kuartal sebelumnya. Solusinya: formulir harus dipraisi dari endpoint retrieve atau catatan internal, sehingga setiap pengiriman selalu berangkat dari total year-to-date yang lengkap. Nol juga harus dikirim, bukan dihilangkan. Pelanggan tetap wajib melapor meski tidak ada aktivitas pada periode tersebut.
Setelah pembaruan diterima, pelanggan biasanya ingin melihat estimasi pajak. Untuk itu, Individual Calculations API dipakai secara asinkron. Aplikasi memicu kalkulasi in-year, menerima calculationId, menunggu sedikitnya lima detik, lalu mengambil hasilnya. Jika belum siap, endpoint dapat mengembalikan 404 Not Found; hanya kondisi ini yang layak diulang dengan retry pendek. Angka utama yang ditampilkan biasanya totalIncomeTaxAndNicsDue, disertai metadata periodTo agar pengguna tahu sampai tanggal mana data dihitung. Namun HMRC mewajibkan penafian: kalkulasi hanya berdasarkan informasi yang telah diterima sampai tanggal tertentu dan dapat berubah selama tahun pajak berjalan. Ada pula sejumlah jebakan sandbox. Data default bisa berasal dari tahun pajak lama dan ditolak endpoint kumulatif dengan RULE_TAX_YEAR_NOT_SUPPORTED, sehingga skenario DYNAMIC diperlukan. Status fulfilled dapat tertunda sampai satu jam setelah 204. Pengiriman terlalu dini, lebih dari 10 hari sebelum akhir periode, juga ditolak. Bagi pengembang yang bersiap meluncurkan produk, ada catatan bisnis yang tak kalah penting: halaman API HMRC memuat pemberitahuan bahwa permintaan kredensial produksi baru untuk produk pembaruan kuartalan 2026-2027 tidak lagi diterima, meski sandbox tetap terbuka untuk pengujian.