PT PMA KBLI Correction Sequence Before Operations
A wrong KBLI is not fixed by editing one portal field; the legal purpose, OSS project, risk-based license, premises, tax, bank, and contracts may all depend on the activity.
When a PT PMA discovers the wrong KBLI, first stop unsupported operations and map what the company actually plans to do. Identify products and services, customers, delivery method, premises, equipment, imports, regulated features, project locations, workers, contracts, and revenue flows. Then compare those facts with the company's deed and AHU record, current KBLI classification, OSS business and project data, risk level, licenses, sector approvals, investment plan, tax profile, bank KYC, and signed commitments.
After a wrong KBLI is identified, use a controlled correction sequence: contain unsupported activity, document the root cause, confirm the correct code and foreign-investment conditions, align deed and AHU data where required, update OSS and dependent licenses, revalidate tax, bank, contract, and premises records, and release operations only when the evidence is complete. The KBLI activity-update requirements can support an expansion case; an error correction should begin with the first incorrect record and follow every downstream dependency.
In this article
Key takeaways
- Freeze the affected activity and contracts until its current permission status is evidenced.
- Map the real activity before selecting or converting a KBLI code.
- Sequence notary or AHU, OSS, sector, tax, bank, premises, and contract updates by dependency.
- Do not treat an NIB, draft change, or inactive certificate as operational permission.
Diagnose the KBLI error
Map the real activity, legal and OSS records, risk, licenses, contracts, tax, bank, and existing exposure.
Contain the wrong-KBLI risk
Open an incident record with the discovered code, current legal and OSS records, affected activity, locations, customers, contracts, invoices, workers, imports, assets, marketing, tax positions, bank descriptions, and dates. Classify whether the issue is a typo, obsolete classification, missing activity, overly broad activity, deed mismatch, project-data error, risk-level misunderstanding, location problem, or missing sector approval. Suspend new commitments for the affected activity until the status and lawful interim route are confirmed.
OSS currently presents risk-based licensing in four risk levels and provides a searchable KBLI classification and licensing context. Use the official OSS KBLI search as a starting point, then confirm the exact activity description, exclusions, risk result, project facts, foreign ownership, and sector rules. A similar phrase in a marketing deck is not enough to choose the code.
Preserve the pre-correction evidence: deed, AHU profile, NIB, standard certificate or license status, sector permits, OSS screenshots and exports, project data, prior advice, contracts, invoices, tax records, bank KYC, and correspondence. Do not delete the old code or backdate a corrected scope. Obtain Indonesian legal and licensing advice on existing contracts, revenue, employees, imports, and any authority notification or remediation required.
| Error type | Immediate question | Containment |
|---|---|---|
| Wrong activity description | What does the company actually sell and perform? | Pause new commitments and map the operating facts |
| Deed and OSS mismatch | Which record must change first and through whom? | Freeze dependent license submissions |
| Risk or sector gap | What verification, certificate, permit, premises, or technical evidence is missing? | Do not operate on an unverified status |
| Legacy code conversion | How does the current KBLI version map and what data changes follow? | Preserve old and converted records with review |
Select and approve the correct activity map
Write one activity memo per revenue stream. Describe the product or service, provider and customer, production or delivery steps, technology, premises, equipment, regulated attributes, imports or exports, project location, ownership, and expected contracts. Compare the memo with candidate KBLI descriptions and exclusions. If multiple activities are genuinely performed, map each one and explain primary and supporting roles rather than forcing the business into one convenient code.
OSS published an official KBLI 2020-to-2025 conversion guide and indicates that older codes may require notary and AHU adjustment or an OSS business-data review before conversion. Follow the current route presented for the company's record; do not assume the conversion is a simple one-to-one renumbering or that the guide resolves sector interpretation.
Approve a target-state matrix showing the final code, title, business description, deed wording, foreign ownership check, project and location, investment data, risk level, NIB effect, standard certificate or license, PB UMKU or sector approvals, premises evidence, responsible technical roles, tax and customs effects, bank narrative, and contract language. Record ambiguities and authority consultations. The Indonesia KBLI directory can orient the analysis but cannot replace current official and sector review.
Activity fact
Document what is sold, made, delivered, operated, imported, stored, advised, or licensed in real life.
Classification fact
Record candidate codes, descriptions, inclusions, exclusions, version, ownership and sector review, and adviser conclusion.
Target state
Map deed, AHU, OSS, project, location, risk, license, tax, bank, contracts, people, and evidence for each code.
Plan the correction sequence
Order corporate, AHU, OSS, sector, tax, bank, premises, and contract steps by dependency.
Sequence AHU, OSS, and sector corrections
Build a dependency plan rather than submitting changes in parallel without control. Determine whether the deed or corporate purpose must be amended, which shareholder or board approvals are required, what the notary submits to AHU, when updated company data becomes available to OSS, which business and project fields change, whether an NIB is updated or reissued, and which risk-based or sector process follows. Record what remains valid during the transition and which activity must remain stopped.
OSS provides a current guide library for changing business-actor data and business licenses. AHU is the official corporate-services portal for limited-company records. Use the current workflows and obtain authority guidance when integration data does not synchronize; avoid repeated uncontrolled edits that make it unclear which version was accepted.
At every milestone, save the submitted data, supporting documents, user, timestamp, receipt, status, authority request, response, and final record. Separate submitted, verified, approved, effective, active, and operational statuses. If a standard certificate needs verification or a sector license needs inspection, technical evidence, or premises readiness, the NIB does not substitute for that outcome. Keep the existing license condition tracker updated through the transition.
Corporate layer
Approvals, deed wording, notary submission, AHU acceptance or notification, and current company profile.
OSS layer
Business actor, business activity, project, location, investment, NIB, risk result, certificate or license status.
Sector layer
Technical standard, responsible role, premises, inspection, recommendation, verification, permit, and operating condition.
Revalidate downstream records and go live
After the core correction, compare the final activity and permissions with tax registrations and invoice treatment, customs or import status, bank KYC and expected transactions, registered and operating premises, employment roles, immigration sponsorship, contracts, insurance, data processing, marketing claims, and accounting segments. Not every downstream record changes, but each owner should document the review and update or no-change conclusion.
The official OSS portal explains that risk level determines licensing and obligations. Re-run the OSS risk-based licensing check for the final activity, location, scale, and project facts. Confirm that any conditions, verification, PB UMKU, sector approvals, environmental, building, zoning, or location dependencies have evidence before commercial operation.
Use a go-live certificate signed by legal, licensing, tax, finance, operations, and management. It should list the final KBLI, corporate and OSS records, effective permissions, limitations, approved premises, contracts, invoice and bank setup, reporting duties, residual risks, and monitoring dates. Test one transaction end to end. If the evidence cannot support operation, keep the activity on hold and escalate instead of treating the correction submission as completion.
Downstream review
Tax, customs, bank, premises, people, immigration, contracts, insurance, marketing, systems, and accounting.
Transaction test
Contract, authority, license, invoice, tax, delivery, payment, ledger, and reporting for one representative transaction.
Release evidence
Final records, conditions, active status, limitations, named owners, monitoring dates, and management approval.
Official references and review basis
The following primary sources were checked on August 1, 2026. They establish the regulatory or service boundary used in this article; bank, tax office, OSS, AHU, and immigration decisions can still depend on the current record and the facts of a particular application.
- OSS — KBLI search — Current official search and business-activity classification context, including KBLI 2025.
- OSS — KBLI 2020-to-2025 conversion guide — Current official guidance on conversion and the dependency on AHU or OSS business data.
- OSS — Guide library — Official current guide index for business-actor and licensing changes.
- AHU — Limited Liability Company services — Official corporate-services portal context for company establishment and amendments.
The go-live test after a PT PMA KBLI correction
The company may release the corrected activity only when its real operating facts map to the final KBLI, deed and AHU records, OSS business and project data, risk result, active certificates or licenses, sector and premises conditions, tax and bank profiles, contracts, people, and reporting controls. A submission receipt or NIB alone does not prove every operational dependency.
Record any uncertainty as a restriction and obtain current Indonesian legal, licensing, tax, and sector advice. Preserve the old and new evidence chain and test a representative transaction before scale-up. If the correction is part of a wider business change, use the Indonesia company registration framework to coordinate corporate, licensing, tax, banking, and operating work.
Run the go-live test
Verify active permissions and one complete transaction before releasing the corrected activity.
Frequently asked questions
