INDONESIA OSS LICENSING
Online Single Submission in Indonesia: Business Licensing After Entity Formation
Trace company data to the activity-specific licensing status.
After forming an Indonesian company, use Online Single Submission (OSS) to record the business and project activities and obtain the risk-based outputs applicable to them. The NIB is an important business identity and can be the business licence for a low-risk activity, but other activities can require a standard certificate, verification, licence or additional approvals before the intended operation starts.
Key takeaways
- Reconcile the company’s legal-entity data before creating or accessing its OSS record.
- Describe the real activity and site before choosing a current KBLI classification.
- Risk level, applicable conditions and output status matter more than a generic statement that the company is registered.
- The NIB and any standard certificate, licence or supporting approval must be checked against the first planned activity.
- Retain access, decisions and change history so the company can update its licensing record.
Reconcile the entity before entering OSS
Begin with the executed deed and Ministry legal-entity output, then confirm the legal name, establishment reference, owners, management and company address. Agree who is authorized to act for the business and who will control the registered email, phone, login and account recovery. The company should be able to access its own records even if an agent prepares the application.
OSS is the online system for risk-based business licensing, while the company formation record establishes a different part of the legal file. Before submitting, compare the intended activity and location with the company’s corporate purpose and available premises information. If there is a mismatch, ask the notary and licensing adviser whether a corporate amendment or a different project description is needed; do not hide a mismatch by selecting a convenient but inaccurate code.
For the wider Indonesia company registration process , treat the handover of source documents, system access and official outputs as a deliverable. Establishing the entity is the starting point for this licensing workflow, not the final evidence that each business activity can operate.
| Stage | Check | Owner | Evidence |
|---|---|---|---|
| Entity | Legal name and AHU record | Company officer | Approved legal-entity documents |
| Project | Activity, KBLI and actual site | Operations lead | Current classification and location record |
| Risk output | Risk band and requested document | Licensing lead | NIB and relevant certificate or licence |
| Launch condition | First activity and open requirements | Project owner | Verified status and retained evidence |
Reconcile the company record
Confirm the authorized business data and account owner before filing.
Describe the activity and project before choosing KBLI
Write a short activity statement explaining what the company actually makes, sells, imports, stores or provides; the customer; the method and place of delivery; and the first activity it expects to perform. A general description such as ‘technology’ or ‘trading’ may conceal materially different tasks. Separate a planned office activity from a warehouse, factory or service site when the facts or licensing outputs differ.
Use the current OSS KBLI directory to review the scope and wording of each potential business classification. A 2020-to-2025 code conversion is not always a one-to-one substitution: the OSS conversion guide identifies unchanged, changed, split, merged and reorganized categories and asks users to review the current description. Record the source and date of the classification decision.
Identify site information and any basic requirements displayed for the actual project. Spatial use, environmental, building and sector conditions can be relevant, but the applicable route depends on the activity and project. A lease by itself is not proof that a site is suitable for every use. Resolve material discrepancies before the company commits to a site, equipment or customer launch.
Interpret the risk result and its legal outputs
Government Regulation 28 of 2025 establishes the risk-based framework and revoked the earlier PP 5/2021. The regulation’s annex distinguishes low, medium-low, medium-high and high risk. The exact classification and conditions depend on the activity and current rules, so inspect the live output for each project rather than applying a single company-wide assumption.
At a high level, low-risk licensing uses the NIB; medium-risk activities use an NIB and a standard certificate; high-risk activities use an NIB and a licence. The details of self-declaration, verification and when an activity may begin differ by risk and applicable conditions. A medium-high result may require verification before the relevant operational or commercial activity; a high-risk result requires attention to the authority’s licence decision and any applicable standard. Check the displayed status and sector requirements, not just the document title.
For each activity, record its KBLI and description, location, displayed risk, requested output, status, outstanding conditions, responsible authority and earliest permitted action. If an output is pending, unverified or tied to additional requirements, assign an owner and record the next step. Do not label a project ‘licensed’ solely because the company has an NIB for another activity.
Resolve the risk outcome
Identify pending certificates, verification and site conditions.
Work through the submission and retain evidence
Use the current official OSS guidance for the applicant category and the specific process; menu names and screen sequences can change. Enter the authorized company and project data, review the business activities and proposed location, and upload or declare the information requested by the current workflow. Confirm that every declaration is accurate and approved by someone who can answer for it.
Save the submitted data, application reference, date, screen or downloadable acknowledgement, and any authority request for correction. If the system shows a deficiency, record the exact field, requested evidence and deadline, then make the correction through the proper channel. Preserve the superseded submission and explain the change so the company can reconcile its final records with the source documents.
When outputs become available, download the NIB and any applicable certificates, licences or notices. Compare the legal name, activity description, KBLI, site and current status to the project file. If an authority or system output contains an apparent error, seek correction rather than assuming the discrepancy is harmless. Keep the company’s control of its account and recovery options after any provider handover.
Connect each licence status to the first intended action
A practical launch review asks which document and condition allows the specific next event: occupying a site, importing a product, signing a customer agreement, starting production or delivering a service. The answer may involve OSS, another authority, product approvals, customs or premises rules. The review should name the responsible entity and authority and cite the actual official status; it should not treat a commercial target date as permission.
For example, a company may obtain an NIB while an activity-specific verification is still in progress. The operational owner should identify which preparatory actions are permitted and whether the planned commercial activity must wait for verification. Another project with a different KBLI or location may yield a different result. These examples illustrate a decision method, not a universal classification for a particular sector.
The risk-based business licensing guide discusses the broader permission stack. Keep a project-level register rather than assuming the first approved output applies to every site, product and activity.
Maintain the record after the first output
Assign an owner for each declaration, certificate, licence, inspection, renewal and continuing obligation shown in the current record. Put any deadline or reporting responsibility on a calendar, together with the source and responsible person. A self-declaration is an obligation to comply with the relevant standards, not merely a box that can be forgotten after issue.
Review the OSS file when the business adds a site, changes its actual activity, changes relevant company data or receives a new authority instruction. Compare the old and new KBLI descriptions during classification transitions and follow the current process for legacy projects where applicable. Keep a dated change log and confirm whether tax, company, bank or other agency records need separate updates.
Release the first operation only after the responsible manager has matched the entity, site, activity, output status and outstanding conditions to the intended action. If a material condition is unresolved, record the question and seek written clarification from OSS or the relevant authority before proceeding. This release check is an internal decision tool, not an official approval or a guarantee of a government outcome.
Check the first operation
Match the intended activity to its current permission status.
Frequently asked questions
Is OSS the same as company formation?
No. Corporate legal-entity formation and risk-based business licensing are related but distinct processes.
Is an NIB enough for every company activity?
No. The applicable risk result and conditions for each activity determine whether further outputs or approvals are required.
Can an agent control the OSS account permanently?
Arrange for authorized company control and recovery, and confirm the actual access setup during handover.
Is an old KBLI always equivalent to one new code?
No. OSS describes several conversion patterns, including splits and mergers; review the current activity description.
What if the system requests correction?
Record the request, provide the relevant evidence through the correct process, and retain the revised submission and final status.
