Indonesia License Risk-Level Changes After a KBLI or Location Update

A KBLI or project-location update can change the risk classification, licence product, verification route, supporting approvals, premises conditions, and the point at which an Indonesian company may operate. Under Government Regulation No. 28 of 2025 , risk-based business licensing is assessed for the relevant activity. Preserve the old OSS output, model the proposed activity-location record, and approve the delta before editing live data or continuing affected operations.

The same five-digit activity can produce different practical dependencies when scale, product, sector, or location changes, while a new KBLI can affect ownership and investment assumptions even at the same site. The review should distinguish a data correction from a substantive expansion, keep existing licensed operations visible, and identify which old permissions remain usable, which require change, and which new conditions block launch.

Risk-level change review decision controls

Use the control, evidence, and release condition together; no single document should carry more meaning than it actually proves.

Key takeaways

• Do not file until the old state, proposed state, and affected operations are separately recorded.
• Treat every changed risk, licence, or verification field as a release dependency.
• Resolve authoritative corporate and investment changes before populating dependent OSS fields.
• Use a change plan that preserves valid records and stops only operations lacking the required new state.
• Release the changed activity only after every mandatory condition is effective or documented as not applicable.

In this article

• Freeze the comparison states
• Recalculate risk and licences
• Test corporate dependencies
• Protect existing operations
• Regulatory Notes and Limitations
• Official References and Review Basis
• Approve the new operating gate
• Release the changed activity from the new risk-and-licence state

Freeze the old and proposed activity-location states

The control file must show how the company will describe the old and proposed KBLI, scale, product, operating method, and parcel without overwriting either state. For freeze the old and proposed activity-location states, the live OSS output, not a generic description of the system, determines which activity, project, licence state, condition, and follow-up record needs attention.

If the baseline is lost, the team cannot prove which licence condition changed or protect unaffected operations. A reviewer should trace old and proposed oss exports and plain-language activity narratives to current authoritative records and actual operating evidence, rather than a copied template, provider promise, or unexplained portal label.

For freeze the old and proposed activity-location states, the practical deliverable is a version-controlled decision row that remains usable when the activity, location, counterparty, or responsible person changes. It should connect old and proposed oss exports with plain-language activity narratives, then show how scale and project-location data and existing operating and licence map affect the next approval. Record the source for old and proposed oss exports, the reviewer of plain-language activity narratives, the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

• Old and proposed OSS exports
• Plain-language activity narratives
• Scale and project-location data
• Existing operating and licence map

For freeze the old and proposed activity-location states, close the stage only when the authoritative record and the operating evidence agree, or when an unresolved difference has a named owner and stop condition.

Recalculate risk and licence outputs

For risk-level change review, test the proposed facts against the current OSS risk output and required business licence. For recalculate risk and licence outputs, the live OSS output, not a generic description of the system, determines which activity, project, licence state, condition, and follow-up record needs attention.

A label such as medium risk does not show whether verification, a permit, or a supporting approval is effective. A reviewer should trace current oss risk result and nib, certificate, or permit state to current authoritative records and actual operating evidence, rather than a copied template, provider promise, or unexplained portal label.

For recalculate risk and licence outputs, implementation should convert this stage into a dated control record rather than a conversation summary. It should connect current oss risk result with nib, certificate, or permit state, then show how verification and pb-umku status and authority and sector conditions affect the next approval. Record the source for current oss risk result, the reviewer of nib, certificate, or permit state, the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

• Current OSS risk result
• NIB, certificate, or permit state
• Verification and PB-UMKU status
• Authority and sector conditions

For recalculate risk and licence outputs, the output should name the owner, source evidence, unresolved condition, acceptance test, and the event that permits the next step.

Test ownership, investment, and corporate dependencies

The responsible team should screen the new code and location against the investment-business-field rules, approved investment plan, deed purpose, and ownership structure. For test ownership, investment, and corporate dependencies, the live OSS output, not a generic description of the system, determines which activity, project, licence state, condition, and follow-up record needs attention.

A licence update can fail or create a corporate mismatch when the new activity has different foreign-investment or project assumptions. A reviewer should trace deed and ahu purpose and perpres 10/2021 as amended to current authoritative records and actual operating evidence, rather than a copied template, provider promise, or unexplained portal label.

For test ownership, investment, and corporate dependencies, the evidence file for this stage should let a new reviewer reproduce the decision without asking the original provider what happened. It should connect deed and ahu purpose with perpres 10/2021 as amended, then show how investment plan by activity and site and shareholder and capital approvals affect the next approval. Record the source for deed and ahu purpose, the reviewer of perpres 10/2021 as amended, the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

• Deed and AHU purpose
• Perpres 10/2021 as amended
• Investment plan by activity and site
• Shareholder and capital approvals

For test ownership, investment, and corporate dependencies, preserve the source record, reviewer, date, exception, and approval so another team can reproduce the decision without relying on memory. For the adjacent control framework, compare Indonesia Risk-Based Licensing for PT PMA Companies . Where this stage changes another workstream, review Adding Business Activities to a PT PMA .

Protect existing licences during the update

A supportable decision begins when the company can identify which existing projects, licences, customers, and sites are unaffected and how they will remain controlled during filing. For protect existing licences during the update, the live OSS output, not a generic description of the system, determines which activity, project, licence state, condition, and follow-up record needs attention.

Deleting, replacing, or misassigning a project can disrupt valid activity while the company is trying to add or repair another. A reviewer should trace unaffected licence register and project identifiers and dependencies to current authoritative records and actual operating evidence, rather than a copied template, provider promise, or unexplained portal label.

For protect existing licences during the update, operational ownership matters here because the same fact may be presented differently in corporate, licensing, tax, bank, contract, and site records. It should connect unaffected licence register with project identifiers and dependencies, then show how change window and rollback evidence and customer and staff instructions affect the next approval. Record the source for unaffected licence register, the reviewer of project identifiers and dependencies, the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

• Unaffected licence register
• Project identifiers and dependencies
• Change window and rollback evidence
• Customer and staff instructions

For protect existing licences during the update, turn the result into a controlled work item with a responsible person, due date, evidence location, escalation path, and release condition.

Regulatory Notes and Limitations

Indonesia License Risk-Level Changes After a KBLI or Location Update provides a decision and evidence framework, not a universal legal opinion. Review the current official output and company-specific facts before filing, contracting, paying, or operating.

• For Indonesia License Risk-Level Changes After a KBLI or Location Update, an NIB is an official business identity, but the licence state required to operate depends on the activity, risk level, location, and supporting approvals shown in OSS.
• For Indonesia License Risk-Level Changes After a KBLI or Location Update, oSS workflow screens and document labels should be checked at execution because system implementation and transition treatment can change.
• For Indonesia License Risk-Level Changes After a KBLI or Location Update, a government-issued record does not replace tax, corporate, bank, premises, product, or sector evidence that another authority or counterparty may require.

Official References and Review Basis

Primary materials for Indonesia License Risk-Level Changes After a KBLI or Location Update were checked on August 4, 2026 and support this page's framework; they do not replace a matter-specific legal, tax, licensing, accounting, security, premises, or bank review of Indonesia License Risk-Level Changes After a KBLI or Location Update.

• Government Regulation No. 28 of 2025 : Current risk-based business licensing framework; it revoked Government Regulation No. 5 of 2021.
• Ministry of Investment and Downstream Industry/BKPM Regulation No. 5 of 2025 : Current OSS procedures, investment facilities, supervision, and reporting framework.
• Online Single Submission portal : Official NIB, four-level risk classification, business licensing, KBLI, and support portal.
• BPS KBLI 2020–2025 conversion table : Official correspondence table for reviewing changes between KBLI 2020 and KBLI 2025.
• Presidential Regulation No. 10 of 2021 : Investment business-field framework, as amended.
• Presidential Regulation No. 49 of 2021 : Current amendment to the investment business-field framework.

Approve the post-update operating gate

Before the next commitment, management should reconcile the live updated record with corporate, premises, tax, bank, contract, and operational evidence before first use. For approve the post-update operating gate, the live OSS output, not a generic description of the system, determines which activity, project, licence state, condition, and follow-up record needs attention.

A portal submission can succeed while a verification or downstream update remains incomplete. A reviewer should trace before-and-after oss records and effective licence and verification evidence to current authoritative records and actual operating evidence, rather than a copied template, provider promise, or unexplained portal label.

For approve the post-update operating gate, a defensible review separates facts already evidenced, facts requested but not received, assumptions approved for planning, and conditions that still block release. It should connect before-and-after oss records with effective licence and verification evidence, then show how updated dependent records and written operating release approval affect the next approval. Record the source for before-and-after oss records, the reviewer of effective licence and verification evidence, the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

• Before-and-after OSS records
• Effective licence and verification evidence
• Updated dependent records
• Written operating release approval

For approve the post-update operating gate, record both the accepted position and the rejected alternatives; this prevents a later portal edit or provider message from silently changing the decision.

Place the risk-level change review decision inside HSJGlobal’s Indonesia company registration scope before executing documents, filings, or funding.

Release the changed activity from the new risk-and-licence state

A KBLI or location edit should produce a controlled before-and-after record, not simply a new PDF. Management needs to know what changed, what remained valid, and which new licence or verification state governs operations.

Keep the delta file with the corporate approvals, site evidence, live OSS outputs, and operating release so later teams do not mistake submission for authorization.

Related insights

• Indonesia Risk-Based Licensing for PT PMA Companies
• Adding Business Activities to a PT PMA
• PT PMA License Condition Tracker After Registration