Sector-Specific Business Licences in Indonesia: Check the Regulator and Application Route

Define the activity that needs permission

Start with an activity statement that another person can test against the proposed contracts: what the Indonesian entity supplies, who receives it, where the work happens and which party takes responsibility. A product name or an investor presentation often leaves those points unresolved. For a digital service, describe what the system does with payments, customer information and financial decisions. For goods, distinguish manufacture, import, distribution and product release.

Create one activity record for each materially different function. Include the legal operator, relevant business classification, location, product or service, intended customer and proposed start condition. Then attach the supporting rule or official service description. This is a planning record, not a government form, and it should expose assumptions before they become filing errors.

Use the live OSS business-classification catalogue when matching Klasifikasi Baku Lapangan Usaha Indonesia (KBLI) codes; the public catalogue currently labels its classification KBLI 2025 and offers a conversion check from KBLI 2020. Compare the activity description as well as the number. An old code in a spreadsheet is a reason to reconcile the records, not a reason to guess a replacement.

The corporate workstream also needs a defined endpoint. forming a company in Indonesia establishes the underlying entity and registration records; the licence plan must then identify the permissions that cover its actual operations. Legal-entity formation and permission to perform a regulated activity are separate completion tests.

Before committing to shareholders, premises or a launch contract, flag any sector conditions that could change those choices. Obtain a project-specific reading of those conditions rather than borrowing another company's result. The same commercial label can describe an unregulated supplier, a licensed operator or a business supporting a licensed institution.

Match the regulator to the submission route

For an Indonesian business, match the proposed function to its responsible authority, then use that authority's published submission channel and required output. OSS business licensing may coexist with a specialist application or product approval. The crosswalk separates those jobs; a portal account or filing receipt should never be substituted for the approval in its final column.

Bank Indonesia's portal notice distinguishes new and ongoing applications from 28 February 2025. Use that distinction when locating an existing case; an old bookmark is not evidence that a new file belongs there. For a business whose model could cross financial regulatory boundaries, financial technology and payment licensing choices should be resolved before incorporation assumptions are fixed.

OJK's current licensing instructions specifically direct ICS and FSAO applicants away from FSTI Registration and into SPRINT Business Licensing. Separately, OJK's SPRINT transition announcement confirms the transfer of SIJINGGA licensing services into SPRINT. Neither instruction means that every financial business uses the same application module.

BPOM's processed-food service guidance identifies e-Reg RBA as integrated with OSS. Integration does not make a product authorization identical to the operator's NIB. Keep the business, facility and product records connected, while tracking each required result separately. These examples are route checks, not findings that a particular product or service qualifies for a licence.

A company can follow more than one lane. The diagram joins the filing routes at the point where their outputs must describe the same operator and proposed scope.

Read the OSS output for each risk level

For an OSS activity, risk level determines the business-licensing output . It does not settle every product, facility or specialist regulatory question. Save the activity-specific result rather than applying a company-wide label such as low risk to every line of business.

The OSS output guide illustrates issued records and the distinction between submission and verification; BPOM's operator requirements also distinguish Standard Certificates, verified certificates and licences by business risk. Use current project records for the actual result. A downloadable document must be read together with its status and conditions.

Perizinan Berusaha untuk Menunjang Kegiatan Usaha (PB UMKU) concerns supporting business activities within the PP 28/2025 framework . Its presence in a licensing plan is a prompt to identify the particular supporting authorization and recipient. Do not use PB UMKU as an interchangeable name for every sector licence or assume one supporting approval covers all products.

Prepare a route-specific submission and evidence trail

Prepare a separate submission pack for each required route, linked by one consistent activity record. The sequence below is a practical control method. It avoids presenting a generic document list as the legal checklist for every regulator.

1. Assign the applicant and access holder. Record the company name, NIB where applicable, authorized representative and official email used for the case. Keep access and correspondence recoverable by the business rather than relying on a single intermediary's inbox.
2. Capture the route evidence. Save the authority's instruction, the selected subsector or module, the required approval and the rule version checked. For the FSTI-related routes described by OJK, account access in SPRINT and SIPO and settlement of the SIPO registration invoice precede completing the licensing application; use the relevant subsector requirements.
3. Build the requirement register. Put each requested document beside its purpose, issuer, signer, version and dependency. Separate company records from facility, product, technical, governance or personnel evidence. Mark an item not applicable only when the rule and actual business support that conclusion.
4. Submit and preserve the transaction. Retain the application reference, submitted version, attachments, any official payment record and the acknowledgement. Those records prove what was filed; they do not prove approval. If a requirement is unclear, resolve that point before certifying a statement.
5. Close the case against its actual output. Download the issued authorization and relevant attachments, check the operator and scope, and record outstanding conditions, validity and any follow-up obligation shown. Confirm the matching status in the appropriate system and retain the decision correspondence.

OJK publishes the SPRINT/SIPO preparation sequence in its licensing process description ; it should not be generalized to BI, BPOM or ordinary OSS applications. Likewise, BPOM's e-Reg RBA update notice identifies its own application developments. Enter specialist services through their official instructions rather than a search advertisement or a portal copied from another sector's checklist.

Keep a short dependency note wherever one result unlocks another. For example, a product-registration pack may depend on the operator and facility evidence specified by BPOM. Schedule document preparation around that dependency; do not treat a successfully created product account as permission to release the product.

The launch test is the authorized scope, not the existence of an application number. Ask the person responsible for the activity to match the final output to the intended transaction, location and product. If the match depends on an assumption, leave that item open in the register.

Resolve a routing error before resubmitting

Repair a routing error at the point where the evidence stops matching the proposed activity. Do not create a second application simply because the first case is difficult to find. Start by preserving the existing reference and correspondence, then establish whether the issue concerns classification, the application module, incomplete evidence or an actual licensing decision.

Use the symptom to choose the correction

• An activity is described differently across records: reconcile the commercial scope and underlying company data first, then determine which records require an authorized amendment. A convenient code should not be used to conceal the activity.
• A familiar portal has no new-application route: check the official transition notice and case date. Preserve continuity of the existing case and follow the authority's instruction before moving or recreating it.
• The regulator is right but the application is in the wrong module: identify the intended decision and correct module. For ICS/FSAO, OJK's express distinction from FSTI Registration is a concrete example of this problem.
• An upload succeeded but approval is absent: inspect the requirement status and decision correspondence. Supply the specific missing evidence through the designated case route and keep the revised version tied to the original request.

For a system fault, send the technical support channel the case reference, affected function, time and a concise description of the error. For a question about legal scope or a substantive requirement, identify the responsible licensing authority in the enquiry. Portal support and licensing discretion serve different purposes; a technical fix does not determine eligibility.

Fix the licence route before committing to launch

Set the order of work from the unresolved decision. If the activity itself is unclear, finish the operator-and-function record first. If the regulator is identified, lock the correct route and application module before preparing the full pack. If a case is already filed, reconcile its status and outstanding requirements before promising a launch date.

Commit to the regulated activity only when the required outputs support the planned scope and their conditions have been addressed. Keep a named owner for every remaining obligation and reopen the route assessment when the operator, function, product or location changes. A licence plan is complete when the business can explain what each approval permits and produce the evidence behind that explanation.