Blocked NIB in Indonesia: Why It Happens After Issuance and How to Restore It

A blocked NIB does not arrive with much warning. One day the company’s OSS dashboard is accessible and licensing is running normally. The next, access is suspended and the consequences spread immediately across every function that depends on OSS being active: work permit processing stalls, import approvals cannot be obtained, tax report filing through OSS is blocked, and any pending license renewals freeze in place.

This is not a hypothetical scenario. Indonesian business licensing consultants documented in May 2026 that consistent failure to submit Investment Activity Reports (LKPM) is one of the primary reasons for NIB blocking in 2026, and compliance monitoring specialists noted that companies failing to monitor their OSS dashboard for compliance notifications risk having their NIB frozen without realizing it until a downstream process surfaces the problem. The NIB is not simply a registration number that stays valid indefinitely. It requires ongoing compliance across multiple government systems to remain active, and the connections between those systems have tightened significantly under PP No. 28 of 2025.

Understanding why the NIB was blocked determines how to restore it. The remediation path for a LKPM-triggered blocking is entirely different from the path for a KBLI misalignment issue, and attempting the wrong fix wastes time that a blocked company rarely has.

What Blocking Actually Means in Practice

Before working through the causes, it is worth being precise about what a blocked NIB removes from a company’s operational capacity, because the scope is broader than most directors realize until it happens.

When the NIB is suspended or revoked under PP No. 28 of 2025, the company loses access to the entire OSS system. The consequences cascade immediately across:

• Work permit and KITAS processing through the OSS-linked immigration system
• Import approvals and customs access, since the NIB functions as the Angka Pengenal Importir (API, or Importer Identification Number) for authorized importers
• Tax report submission through OSS-linked Coretax functions
• New or renewed sector-specific licenses and Standard Certificates
• LKPM submission itself, which creates a compounding problem since the compliance gap that caused the block cannot be addressed without OSS access

Restoring OSS access after NIB revocation is significantly more complex than maintaining compliance in the first place, as Indonesian licensing compliance practitioners noted in May 2026. The difficulty increases with how long the block has been in place, because each missed compliance cycle during the blocking period adds to the remediation workload.

Explore Our Services Business Licensing in Indonesia

Cause One: Missed or Incomplete LKPM Submissions

This is the most frequently cited cause of NIB blocking in 2026. The Investment Activity Report (Laporan Kegiatan Penanaman Modal or LKPM) is a mandatory periodic report under Article 15(c) of Law No. 25 of 2007 on Investment, now enforced through BKPM Regulation No. 5 of 2025. Every company holding a NIB must file LKPM reports, with the frequency determined by business scale. All PT PMA entities, regardless of their actual investment value, are automatically classified as large-scale businesses and must file quarterly.

The sanction structure under BKPM Regulation No. 5 of 2025 is graduated but moves faster than most companies expect:

• First stage: Written warning
• Second stage: Temporary business suspension (pembekuan kegiatan usaha)
• Third stage: Permanent NIB revocation

A company that misses consecutive quarterly LKPM submissions without a documented reason, or that repeatedly submits reports showing zero investment realization without explanation, advances through this sequence. The third stage, permanent revocation, triggers complete OSS access termination.

Diagnostic signals:

• OSS dashboard shows an LKPM compliance notification or warning flag
• One or more quarterly LKPM periods show “not submitted” or “needs improvement” status
• The company has not logged into OSS to verify LKPM status in more than three months

Remediation path:

• Log into OSS immediately and check the LKPM submission history for all active project locations
• Identify which periods are missing or flagged as incomplete
• Prepare and submit all outstanding LKPM reports, starting from the earliest missing period; each report requires investment realization data, workforce figures, and any obstacles encountered
• If reports were submitted but show zero realization, add a written explanation of why realization was delayed or absent; unexplained zero-realization reports are treated as non-compliance
• After submission, confirm with the relevant BKPM regional office or DPMPTSP that the compliance record has been updated before assuming OSS access will be restored automatically

The interaction between LKPM compliance and the broader investment compliance framework under BKPM Regulation No. 5 of 2025 is covered in the NIB validity and compliance guide for Indonesia, which addresses how investment realization data maps against NIB KBLI codes and what inconsistencies trigger BKPM monitoring reviews.

Cause Two: KBLI Misalignment After the June 2026 Transition Deadline

The transition from KBLI 2020 to KBLI 2025 under BPS Regulation No. 7 of 2025 had a formal completion deadline of 18 June 2026. For most companies, the migration was handled automatically: a Joint Circular Letter from the Minister of Investment, the Minister of Law, and the BPS Head confirmed that straightforward numerical code changes would be updated in the OSS and AHU systems without requiring manual intervention. But “most” is not “all.”

Companies whose KBLI codes underwent structural changes in the transition, where a single KBLI 2020 code was split into multiple KBLI 2025 codes, or where several KBLI 2020 codes were merged into one, require manual alignment. A company in this situation that did not verify its NIB data before the June 2026 deadline may now be operating on a KBLI registration that the OSS system no longer recognizes as valid, which can trigger a suspension flag.

There is also a second scenario: companies that changed their business activities after June 2026 and are trying to add a new KBLI code to their NIB, where the requested code belongs to a category that requires a different zoning classification than the company’s current registered address supports. The OSS system rejects the KBLI addition automatically, and in some configurations, this triggers a broader access restriction on the existing NIB.

Diagnostic signals:

• OSS shows a KBLI data inconsistency notification or a flag on one or more registered business activity codes
• A KBLI addition or update was attempted and rejected by OSS, followed by access restrictions
• The company’s NIB data shows KBLI codes in a format that does not correspond to the five-digit KBLI 2025 structure

Remediation path:

• Log into OSS and compare the current KBLI codes on the NIB against the official KBLI 2025 conversion table published by BPS on 23 April 2026
• Identify which codes require manual alignment (one-to-many or many-to-one mapping patterns from the conversion table)
• For codes requiring a deed amendment, initiate the notarial process to update the Articles of Association, followed by AHU re-submission; Permenkum No. 49 of 2025 imposes a mandatory 14-working-day review period at AHU
• For KBLI additions that triggered a zoning conflict, verify whether the registered address’s zone classification supports the new code before resubmitting
• For KBLI codes that were automatically updated by the system but show incorrectly, submit a correction request through the OSS help desk with the relevant BPS conversion table reference

The mechanics of adding KBLI codes to an existing NIB and the zoning compatibility checks that OSS runs automatically are covered in the KBLI 2026 complete guide for foreign investors, which addresses the KBLI 2025 conversion framework and when a deed amendment is required versus when an OSS-level update is sufficient.

Cause Three: BPJS Enrollment Gaps or Outstanding Contribution Arrears

The NIB and OSS licensing system does not operate in isolation from Indonesia’s social security framework. BPJS Kesehatan (national health insurance) and BPJS Ketenagakerjaan (employment social security) enrollment is a prerequisite condition that is verified during OSS licensing reviews. Since 2022, every company with employees is required to register with both BPJS programs and enroll all employees, including foreign workers on KITAS of six months or longer.

Non-compliance with BPJS obligations does not immediately block the NIB. The impact is typically felt at the point of renewal or update: a company attempting to renew a sector-specific license through OSS or update its Standard Certificate may find the process blocked pending BPJS compliance confirmation. For PT PMA entities processing RPTKA (Foreign Worker Utilization Plan) renewals or KITAS extensions, BPJS non-compliance creates a blocking condition that the immigration authority flags separately from OSS. In severe or prolonged cases of non-compliance, BPJS enforcement can escalate to administrative sanctions that affect the company’s OSS standing.

Diagnostic signals:

• A license renewal or Standard Certificate update stalls at a social security compliance verification step
• KITAS or work permit renewals are blocked with a BPJS-related non-compliance notification from the immigration authority
• The company has employees but has never registered with either BPJS program, or has registered the company but not enrolled individual employees

Remediation path:

• Verify the company’s BPJS Kesehatan and BPJS Ketenagakerjaan registration status separately; company registration and employee enrollment are two distinct steps
• For companies with outstanding contribution arrears, calculate the total amount owed including applicable late payment penalties and prepare for voluntary disclosure; proactive disclosure typically results in lower sanctions than enforcement-driven collection
• Register any unregistered employees, including foreign workers with KITAS of six months or longer, and submit enrollment documentation
• After completing enrollment and arrear settlement, obtain a BPJS compliance confirmation and submit it as part of the license renewal process in OSS

Cause Four: AHU-OSS Data Divergence After a Corporate Change

Every PT PMA undergoes corporate changes over time: shareholders change, directors are replaced, registered addresses move, capital is increased. Each of these changes needs to be reflected consistently across three government systems: AHU (the Ministry of Law’s legal entity database), OSS (the licensing system), and Coretax (the tax system). When these systems diverge, the inconsistency can trigger a flag in OSS that restricts NIB access or blocks downstream licensing processes.

The most common version of this problem involves a corporate change that was correctly processed through AHU but never updated in OSS. A director change executed through a notarial deed and registered with Kemenkumham creates a valid legal record, but if the company’s OSS account still shows the previous director as the authorized system user, the account access becomes problematic. A capital increase that was properly documented but not reflected in the OSS investment plan creates an LKPM reporting inconsistency, since the new capital appears in the company’s financial records but does not match the investment plan on file in OSS. A registered address change that updated the AHU record but not the OSS zoning reference can cause OSS to reject license renewals because the system sees an address that no longer matches its spatial compliance record.

Diagnostic signals:

• OSS access shows as active but specific functions, such as LKPM submission or license renewal, return data inconsistency errors
• The authorized OSS account user is no longer with the company or has changed roles
• A recent director appointment, share transfer, or capital change has not been reflected in the OSS system

Remediation path:

• Log into the OSS portal and compare all company data fields against the current AHU record; AHU Online (ahu.go.id) shows the current Ministry of Law registration data and serves as the reference for what OSS should reflect
• Identify which specific fields are inconsistent and submit data corrections through OSS for discrepancies that do not require a deed amendment
• For discrepancies that originated in an incomplete deed amendment process, complete the AHU amendment first, wait for the 14-working-day review under Permenkum No. 49 of 2025 to complete, and then update OSS
• Update the authorized OSS account user if the person who was originally registered as the system user is no longer the correct contact

The process for managing data consistency across AHU, OSS, and Coretax whenever a director or shareholder change is made is addressed in the guide to changing directors and shareholders in a PT PMA, which covers the sequencing that prevents data divergence from accumulating between systems.

Before Resubmitting: The Compliance Gap Assessment

A NIB that has been blocked for more than one compliance cycle accumulates a secondary problem: the compliance gaps that built up during the blocking period. A company that was blocked because of missed LKPM submissions for two quarters now has those two quarters of outstanding reports to file alongside whatever triggered the block in the first place. A company that was blocked because of a BPJS enrollment gap may have months of contribution arrears accumulating while the main issue was being investigated.

Rushing to resolve the primary blocking cause without assessing what has accumulated during the blocking period creates the risk of partial remediation: the NIB appears restored, but the compliance record is still incomplete in ways that will trigger a second blocking event in the next monitoring cycle. A pre-restoration compliance gap assessment, covering all outstanding LKPM periods, BPJS arrears, and OSS data fields, provides a complete picture of what needs to be resolved in the correct sequence.

For PT PMA entities managing these obligations across multiple locations or multiple KBLI codes, the complexity of a full compliance restoration increases accordingly. XPND’s licensing compliance team handles NIB blocking diagnosis, compliance gap assessment, and step-by-step restoration across all four cause categories, including coordination with BKPM regional offices, BPJS registration processing, and OSS data correction submissions.

Reach out to XPND’s licensing team to diagnose the cause of your NIB block and restore OSS access through the correct remediation sequence before the compliance gap compounds further.