Simplifying Country Code Reporting on PPh 26 (BP26) in Coretax in Indonesia
The transition to the Coretax system has fundamentally changed how foreign-owned companies (PT PMA) in Indonesia handle their tax obligations, particularly regarding cross-border payments. For finance teams accustomed to manual data entry or flexible forms, the rigid validation logic of the new system can be a source of frustration and error.
One specific field that causes disproportionate issues is the country code requirement, which is no longer a simple text label but a critical data point that triggers specific tax treatments. If this code is entered incorrectly, the system may fail to recognize the recipient’s non-resident status properly.
The stakes for getting this right are high because the Country Code in Coretax is directly linked to the application of Double Taxation Avoidance Agreements (P3B). A mismatch between the country code entered on the BP26 withholding slip and the domicile listed on the Certificate of Domicile (SKD) can result in the automatic denial of treaty benefits.
This means your company could be liable for the full 20% domestic withholding rate instead of a reduced treaty rate, potentially costing thousands of dollars in overpaid taxes. Rectifying such errors often involves significant administrative burdens, including amendment filings and potential audits.
This guide is designed to demystify the specific requirements for reporting the Country Code in Coretax within the BP26 module. We will explore the legal basis under PER-11/PJ/2025, provide a step-by-step workflow for selecting the correct ISO-style codes, and highlight common pitfalls that lead to audit scrutiny.
By mastering this seemingly small detail, investors and tax managers can ensure seamless compliance and protect their bottom line. For the most accurate and up-to-date regulatory text, always consult the Directorate General of Taxes (DJP).
Table of Contents
- Legal and Technical Basis for Country Code in Coretax in Indonesia
- How to Choose and Enter Country Code in Coretax Correctly
- Role of Country Code in Coretax for Tax Treaty Relief
- Step-by-Step: Simplifying Country Code in Coretax for PT PMA in Bali
- Common Mistakes and Risk Points Around Country Code in Coretax
- Real Story: The Consultant in Seminyak
- "Not Confirmed" Error Codes and Custom Labels
- Practical Compliance Checklist for Finance Teams
- FAQs about Country Code in Coretax
Legal and Technical Basis for Country Code in Coretax in Indonesia
The requirement to input a standardized Country Code in Coretax is not merely a procedural preference but a legal mandate established by PER-11/PJ/2025. This regulation stipulates that all Income Tax Article 26 (PPh 26) withholding slips, known as BP26, must accurately identify the jurisdiction of the non-resident taxpayer (WPLN).
The system utilizes this code to validate the taxpayer’s status against the global database of jurisdictions recognized by the Indonesian government. Without a valid code, the system cannot process the withholding slip effectively.
Appendix A of the regulation provides an official list of 249 country and jurisdiction codes that must be used when populating the field. This list covers sovereign nations as well as specific tax jurisdictions that may have distinct treaty arrangements.
In the BP26 form, this data is entered specifically at Section A.4 (Identity of Income Recipient). Unlike previous systems where “United Kingdom” or “UK” might have been typed manually, the new system enforces strict adherence to the defined code set.
The practical implication for your finance team is that there is zero margin for error when entering the designated country code. The system uses this field to trigger backend logic regarding tax rates and treaty availability.
If the code entered does not exist in the master table or corresponds to a different jurisdiction than intended, the BP26 may be rejected or processed incorrectly. Therefore, understanding the legal weight of this field is the first step toward compliance.
Entering the correct Country Code in Coretax requires familiarity with the specific format adopted by the Directorate General of Taxes. The official list largely follows the ISO 3-letter standard, which is distinct from the 2-letter codes often used in internet domains.
For example, the code for the Netherlands is “NLD,” not “NL” or “Holland.” Similarly, the Philippines is “PHL,” and New Zealand is “NZL.”
Using these precise three-letter combinations is essential for the field to function as intended. When you are filling out the BP26 form, specifically in the identity section, you will encounter fields for the Tax Identification Number (TIN), Name, and Address.
Following these, the Country Code in Coretax field (A.4) requires you to select from the dropdown or key in the code directly. Third-party tax application service providers (PJAP) like Klikpajak or OnlinePajak typically mirror this official list, offering dropdown menus to minimize data entry errors.
However, the ultimate responsibility for selection accuracy lies with the user. A common question arises when a recipient’s country does not appear to have a standard Country Code in Coretax.
According to guidance summaries derived from the regulation, if a specific jurisdiction is genuinely missing from the 249-code list, users are instructed to enter the full name of the country directly into the field. This is an exception rather than the rule.
In 99% of cases, you must find and use the designated three-letter code to ensure the Country Code in Coretax is validated correctly by the system.
The most critical function of the Country Code in Coretax is its role as a bridge between the withholding slip and the tax treaty (P3B) benefits. To apply a reduced withholding rate (e.g., 10% instead of 20%), the non-resident taxpayer must provide a valid Certificate of Domicile (SKD WPLN).
This document is processed via the DJP’s e-SKD module, which generates a specific receipt number. This receipt number must be referenced in the BP26 form to unlock the lower rate.
However, the system performs a cross-check: the jurisdiction listed on the validated SKD must match the code entered on the BP26. If you have an SKD from Singapore but accidentally enter “MYS” (Malaysia) as the Country Code in Coretax, the system will detect a mismatch.
This discrepancy is interpreted as a failure to prove residency in the treaty partner country, leading to the automatic rejection of the treaty rate application. Regulations reiterate that treaty benefits are conditional on the recipient being a tax resident of the treaty partner.
By enforcing a strict match between the SKD and the Country Code in Coretax, the DJP automates the verification of this condition. Consequently, a simple data entry error in this field can result in a mandatory 20% deduction, plus potential interest penalties for underpayment if the error is caught during a later audit.
Accuracy here is directly linked to financial liability.
To ensure your team consistently gets the Country Code in Coretax right, it is helpful to establish a standard workflow. First, classify the payee correctly by confirming they are indeed a non-resident taxpayer (WPLN) without a permanent establishment in Indonesia.
Next, identify their country of tax residence exactly as it appears on their tax residency certificate or SKD. This document is the source of truth for the Country Code in Coretax entry.
Once the residence is confirmed, check if that country has a tax treaty with Indonesia. If a treaty exists and you intend to use it, ensure the SKD WPLN is submitted via e-SKD to obtain the receipt number.
Before entering data into the BP26, map the country name to its official three-letter code using the Lampiran A list. For example, if the SKD says “United Arab Emirates,” know that you need to input “ARE.”
When filling the BP26 identity block, input the TIN, name, and address, then carefully select the pre-determined Country Code in Coretax in field A.4. If you are using a treaty rate, verify one final time that the code matches the SKD exactly.
Insert the SKD receipt number in the treaty section. By making the verification of this field a mandatory step in your review process, you eliminate the most common cause of treaty denial.
Finance teams often fall into the trap of using informal names or outdated abbreviations when entering the Country Code in Coretax. Entering “Holland” instead of “NLD” or “UK” instead of “GBR” are frequent errors that can cause validation failures.
These informal labels do not exist in the system’s logic, rendering the input invalid and potentially flagging the transaction for review. Consistency with the official 249-code list is mandatory.
Another major risk is a mismatch between the BP26 and the supporting documents. For instance, if the SKD is issued by the tax authority of Hong Kong, but the code is set to “CHN” (China) due to confusion about political status, the treaty benefit specific to Hong Kong may be denied.
Such mismatches are strong grounds for the DJP to reject the reduced rate and issue an underpayment assessment (SKPKB). Furthermore, applying a treaty rate without a valid SKD or with an incorrect Country Code in Coretax is a red flag.
Some teams assume that because a treaty exists, they can simply select the lower rate. However, without the correct code linking to a validated SKD, the system views this as under-withholding.
Additionally, inconsistent coding across different forms—such as using one code on the BP26 and a different one on a related expat’s BPA1 form—can raise broader questions about your compliance data.
Justin, a 29-year-old management consultant from Seattle, USA, thought his team was being efficient when they processed a payment to an architectural firm in the Netherlands in mid-2024. To save time, his admin manually typed “HOLLAND” into the portal instead of selecting the official code.
It seemed like a harmless label, until the system’s rigid logic rejected the entry, ignored Justin’s tax treaty benefits, and slapped his company with a 20% tax bill plus months of interest penalties. Because the input was unrecognizable to the system’s treaty validation logic, the 10% treaty rate he had applied was rejected.
The system defaulted the transaction to the standard 20% rate, creating a significant outstanding tax liability. The tax office demanded payment of the difference, plus interest penalties for the months of “underpayment,” turning a routine payment into a costly error.
Frustrated and facing a hefty fine, Justin contacted a professional corporate tax consultancy in Bali. They identified the simple coding error and helped him file a correction (Pembetulan) using the valid Country Code in Coretax.
Although the process was tedious and stressful, rectifying the code allowed the system to recognize the valid SKD and restore the treaty rate. Justin learned that in the world of Coretax, precise country coding is as vital as the payment itself.
While the system is robust, there are still areas regarding the Country Code in Coretax that remain “Not Confirmed” in public documentation. For example, there is no formal, public list of specific “error codes” that the system generates solely for country mismatches.
Users often have to infer the error from generic rejection messages, making troubleshooting difficult. Knowing exactly which entry caused a batch rejection often requires trial and error or consultation with an AR.
Additionally, the handling of jurisdictions not explicitly on the list remains a grey area. While guidance suggests typing the full name, the exact character limit or formatting for these custom entries is not definitively documented.
Relying on a custom entry for the Country Code in Coretax carries a higher risk of manual review by tax officers. It is always safer to double-check if a standard code exists, perhaps under a different official name (e.g., using “Holy See” vs “Vatican”).
There is also no confirmation that “catch-all” codes like “OTH” (Others) will be accepted for this field. Using such generic codes is generally discouraged as it prevents the specific application of treaty benefits.
Until the DJP issues further technical FAQs, sticking strictly to the Lampiran A list is the only prudent strategy. Any deviation from the standard list should be treated as a high-risk compliance action.
To safeguard your company against these risks, integrate a Country Code in Coretax verification step into your monthly closing procedures. Create an internal mapping table that links your common vendors to their specific ISO 3-letter codes.
This ensures that every time a payment is made to a recurring vendor, the same correct code is used, maintaining consistency across tax periods. Before finalizing any BP26, have a second reviewer verify that the code matches the country of residence stated on the vendor’s invoice and SKD.
Check that the SKD receipt number is valid and corresponds to the same jurisdiction. This simple “four-eyes” principle can catch the majority of manual entry errors before they become submitted filings.
Treat this field with the same importance as the transaction value itself. Finally, ensure your tax software or PJAP is updated with the latest code list from PER-11/PJ/2025.
Using outdated software that suggests 2-letter codes or obsolete country names will lead to immediate rejection. Regular training for your finance staff on the importance of the Country Code in Coretax will empower them to spot discrepancies early.
A proactive approach to this data point is a low-cost, high-reward compliance strategy.
The official list of 249 codes is found in Lampiran A.1.e of PER-11/PJ/2025.
A wrong code can lead to the rejection of tax treaty benefits, resulting in a 20% tax rate and potential penalties.
No, you must use the official 3-letter code "GBR" for the United Kingdom.
Yes, the code is essential for validating the SKD, which triggers reduced treaty rates.
You should type the full name of the country directly into the field, as per current guidance.
Yes, if they make payments to overseas partners or service providers.
Need help verifying your country code in Coretax? Chat with our team on WhatsApp now!
