Indonesia Business License: OSS, NIB and Risk-Based Licensing

Key takeaways

• OSS is the integrated licensing system; NIB is a formal business identity within that operating framework.
• The activity description and current KBLI selection are the inputs that make a risk result meaningful.
• Four risk levels do not create a generic document list; the selected activity, location and displayed conditions govern.
• Use a launch gate to separate entity formation, NIB issue, standards or licences, sector controls and live-operation approval.
• Reassess the file when the activity, premises, KBLI, ownership facts or operating model changes.

Place the business licence in an Indonesia launch map

A business licence is one part of a launch system, not a stand-alone object. The system begins with the legal applicant and ends with an operation that can actually perform its planned activity. Between those points sit the chosen KBLI, risk result, NIB, any standard or licence displayed for the activity, premises controls and sector-specific conditions. The sequence matters because a missing or mismatched early fact can change everything downstream.

The official OSS portal calls NIB the formal identity for beginning or running a business and states that four risk levels determine required permissions and obligations. Read this as a routing rule. It does not say that one company, one NIB or one generic activity phrase produces the same operating result for every business.

Version control matters as well. The BPK legal database records that PP 5/2021 was revoked by PP 28/2025. A filing brief built only on an old PP 5/2021 checklist is therefore not a safe basis for a new decision. Confirm the active OSS path, the current KBLI reference and the live output for the selected activity before treating a copied procedure as current.

Build activity dossiers before filing in OSS

Create a short dossier for each activity the company genuinely expects to perform. Do not begin with broad labels such as “trading”, “technology” or “consulting”. State what the company will sell, make, arrange, import, store, deliver or perform; who receives it; where it happens; whether goods cross a border; whether employees or the public enter the site; and which contract or transaction comes first. This gives the person selecting KBLI a factual base instead of a marketing description.

The OSS KBLI 2025 directory provides the current classification reference, and OSS also publishes a KBLI 2020-to-2025 conversion guide. A conversion is an administrative aid, not proof that the old description still matches the planned operation. Re-read the current description and scope whenever a prior code is carried into a new or changed filing.

Keep the dossier beside the company deed, NIB record and final OSS output. It is the audit trail that explains why a particular activity was selected and when that selection needs to be reconsidered.

Trace the risk outcome through a permission stack

The four risk levels are a classification mechanism, not four universal folders of documents. For the selected KBLI and business facts, OSS presents the relevant path and the business must then control the output it receives. The OSS portal publishes a distinct guide for medium-high and high-risk submissions, which is a practical signal that a risk outcome can call for more than merely recording an activity against an entity.

Use a permission stack: first preserve the NIB and selected KBLI; then identify every standard, licence, verification, declaration, approval, timing condition or authority named in the result; finally identify the business fact that supports each one. This avoids the mistaken habit of treating a downloaded document as the whole compliance answer. If the operation involves a regulated product, a special site, import movement, a technical process or a professional service, the remaining layer may be the one that governs the first transaction.

Assign one owner to each layer of the stack. The commercial owner confirms the activity is accurately described; the entity owner confirms the applicant and authority are correct; the operations owner confirms what will happen at the site; and the compliance owner records every condition, deadline and issuing body. A single person may hold more than one role in a smaller business, but the responsibilities should still be named. This turns a portal result into a working control record rather than a document held by an external filer.

Do not make a binary “approved or not approved” assessment from a document name alone. Read its scope, status, conditions, location, activity wording and any stated validity or next action. Then compare each item with the first live event. If a condition cannot be connected to a real business fact, either the internal file is incomplete or the selected activity needs further review before the company commits customers, staff or capital.

This board intentionally asks for the live result rather than promising a fixed output for every activity. The selected code, scope, location and current OSS configuration control the answer. Where the result names another authority, record that relationship and do not substitute an unverified copy of a generic guide.

Read NIB as an identity event, not universal clearance

NIB is valuable because it gives the business a formal identity in the OSS framework. It should be retained with its KBLI list, issue record and any amendments. It does not, by itself, erase the difference between entity formation and operating permission. A business can have an NIB but still need to satisfy a condition connected to the exact activity, site, product, technical standard or other public authority.

Keep these questions separate: Is the Indonesian entity correctly formed? Does the NIB record the intended activity? What risk result is associated with that activity? Which conditions are shown as incomplete, pending, self-declared, verified or authority-issued? May the company carry out its first live event while that state remains? Combining these questions into “we have NIB” removes the very distinctions the risk-based system is designed to show.

Treat the NIB as a controlled identifier. Put the number, entity name, responsible manager, selected activities, issue history and related authority records in one maintained register. When a counterparty, bank, supplier or employee asks what the company is authorised to do, answer from that register and the current OSS output rather than from an isolated PDF. This reduces the risk that a correct identity record is presented as proof of an activity that has not yet reached its required operating state.

For the document and premises discipline that supports those questions, see HSJGlobal’s business licence requirements guide . It can help structure an internal evidence file, while the authoritative Indonesia result remains the current OSS and relevant sector authority output.

Use a launch gate before the first live transaction

The most useful operational decision is a short launch gate held before the first invoice, import, production run, customer delivery, public opening or hire. It should be chaired by the person accountable for the activity, not only by the person who completed an online form. The agenda is evidence-based: compare the first real event with the selected KBLI, NIB record and all displayed OSS conditions.

1. Name the first live event. State exactly what will be supplied, by whom, to whom and from which site.
2. Compare it to the activity dossier. Escalate any mismatch in product, service, premises, customer access, import movement or operating method.
3. Read the current output and every condition. Preserve the status view, dates, linked authority and person responsible for fulfilment.
4. Make a written release decision. Release, hold pending evidence or change the intended operation; then keep that decision with the NIB record.

Keep the decision narrowly tied to the event under review. A release for a modest office-based service does not automatically cover a later warehouse, a public retail outlet, a different product line or an import activity. When the operating model expands, repeat the same comparison instead of relying on an earlier meeting note. This preserves an auditable link between what the company intended to do and the authority record used for that decision.

A launch gate does not replace an authority’s determination. It provides a disciplined internal point at which the business can identify that its facts or documents have moved beyond the approval state it holds.

Use the PP 28 and KBLI 2025 transition as a control trigger

The first OSS output should start a control file, not end it. Appoint an owner for the NIB, account access, KBLI list, certificates or licences, associated authority notices and change calendar. That owner should receive a notice before any new branch, new product line, altered activity, material site change, revised ownership fact, merger, closure or change to the way goods and services are delivered.

The OSS site itself flags the transition to PP 28 and KBLI 2025 in its current materials. It also identifies a legacy-data route for certain projects that had spatial requirements issued before the PP 28 transition but had not completed business licensing. That makes a version review sensible even when the company has made no internal change. Record the date of each review, the current KBLI reference, the source of any transition instruction and whether the live business still matches the record. Do not let a historic NIB printout become the sole evidence of current scope.

Review one activity record at a time

Do not treat a transition as an instruction to make broad, untested changes to every code in the company file. List each existing activity separately, identify the current operating fact and compare it against the relevant KBLI 2025 description or conversion result. A code may remain unchanged, be relabelled, combine with another code or require a narrower scope review. The right outcome depends on the company’s real operation, not on a desire to preserve the shortest historical list.

Set an escalation rule as part of this ledger. If the business proposes a new revenue stream, a new premises use, a cross-border goods flow or a change in who performs the activity, the owner must pause the launch plan long enough to compare the proposal with the current KBLI and OSS position. The value of the rule is not delay for its own sake. It prevents a commercial decision from quietly becoming a licensing change after resources have already been committed.

For company-side planning before the OSS work begins, HSJGlobal’s Indonesia company-formation support can help coordinate entity facts, ownership and the operating brief. The competent authority makes the licensing decision, and the company remains responsible for maintaining the conditions that apply to its activities.

Frequently asked questions