How to Validate an Indonesia NIB Before Relying on a Company

An NIB should be treated as one official identity record, not as proof that an Indonesian company is authorized for every claimed activity. Enter the number in the official OSS NIB search , compare the result with the supplied document, and reconcile the company name and corporate existence against the AHU company profile search . Then test the listed KBLI, project location, risk level, licence outputs, and any verification or supporting approval needed for the transaction.

The validation depth should match the reliance decision. A low-value purchase may need identity and scope checks; a regulated supply, long-term lease, investment, credit exposure, import arrangement, or safety-sensitive service requires direct supporting evidence and possibly confirmation from the issuing authority. A clear NIB search result cannot prove delivery capability, beneficial ownership, tax status, bank ownership, product authorization, or that a licence condition remains satisfied.

In this article

• Authenticate the NIB
• Match the legal entity
• Test the KBLI scope
• Confirm operational authority
• Official References and Review Basis
• Regulatory Notes and Limitations
• Close the reliance decision
• Rely on the NIB only for the facts it actually proves

NIB validation layers

Each layer answers a different question. The file is reliable only when the number, entity, activity, location, licence state, and transaction all align.

Key takeaways

• Search the NIB through the official OSS function and preserve the result with a review date.
• Use AHU to confirm the legal entity; an NIB and an AHU company record answer different questions.
• Read the KBLI description against the supplier's real work instead of accepting a matching keyword.
• Confirm the operational licence state and supporting approvals for the precise product, service, and location.
• Verify that the contract, invoice, tax identity, and beneficiary bank account belong to the same counterparty.

Authenticate the NIB number and supplied file

Start with the number, document date, entity name, address, listed activities, and any QR code or electronic features present in the original output. Search the number through the official OSS field and save the result instead of relying on a screenshot supplied by the counterparty.

A copied template can look convincing while carrying a false number, altered activity, or outdated address. Verification should use a source controlled by the government and should record who performed the check and when.

For authenticate the nib number and supplied file, the evidence file for this stage should let a new reviewer reproduce the decision without asking the original provider what happened. It should connect request the original digital file rather than a cropped image. with search the full nib and capture the official result and date., then show how compare spelling, entity form, address, and activity fields. and escalate missing, inconsistent, or obviously edited information. affect the next approval. Record the source for request the original digital file rather than a cropped image., the reviewer of search the full nib and capture the official result and date., the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

• Request the original digital file rather than a cropped image.
• Search the full NIB and capture the official result and date.
• Compare spelling, entity form, address, and activity fields.
• Escalate missing, inconsistent, or obviously edited information.

Use the fake-NIB risk indicators when the source file or provider behavior raises authenticity concerns.

Reconcile the NIB with the AHU legal entity

The AHU company profile search helps confirm that a limited-liability company exists under the stated identity. Compare the name, place of domicile, and current corporate information available through the proper AHU route with the entity named on the NIB and contract.

A commercial brand, branch description, marketplace store, or bank account label may differ from the registered company. That difference is not automatically improper, but the contracting entity and authority chain must be clear before funds or confidential information are released.

For reconcile the nib with the ahu legal entity, operational ownership matters here because the same fact may be presented differently in corporate, licensing, tax, bank, contract, and site records. It should connect search the registered company name without relying on branding. with compare the current deed and ministry approval where material., then show how identify the signatory and the corporate authority supporting the contract. and record affiliates, agents, distributors, or payment collectors separately. affect the next approval. Record the source for search the registered company name without relying on branding., the reviewer of compare the current deed and ministry approval where material., the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

• Search the registered company name without relying on branding.
• Compare the current deed and Ministry approval where material.
• Identify the signatory and the corporate authority supporting the contract.
• Record affiliates, agents, distributors, or payment collectors separately.

For a wider cross-record review, use the AHU, OSS, tax, and bank document verification workflow .

Test whether the listed KBLI covers the promised work

A listed KBLI should be read against the exact goods, services, customer, delivery method, assets, and location promised under the transaction. The current BPS KBLI correspondence materials are important where a record or contract still refers to KBLI 2020 while KBLI 2025 is being implemented.

A general trading, consulting, software, warehousing, manufacturing, or support label can hide material scope boundaries. The checker should identify whether another activity code, sector licence, product registration, or operational location is needed.

For test whether the listed kbli covers the promised work, 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 describe the deliverable in plain operational language. with check the current code title, description, inclusions, and exclusions., then show how identify manufacturing, import, storage, installation, or after-sales components. and confirm which company and location actually performs each component. affect the next approval. Record the source for describe the deliverable in plain operational language., the reviewer of check the current code title, description, inclusions, and exclusions., the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

• Describe the deliverable in plain operational language.
• Check the current code title, description, inclusions, and exclusions.
• Identify manufacturing, import, storage, installation, or after-sales components.
• Confirm which company and location actually performs each component.

Compare the result with the KBLI selection evidence framework if the promised work spans several activities.

Confirm the licence state for the exact transaction

The current risk-based system uses four risk levels, but the document required to operate depends on the activity and OSS output. Government Regulation No. 28 of 2025 is the current national framework and revoked the earlier 2021 regulation.

A counterparty may hold an NIB while a Standard Certificate, verification, permit, product approval, premises condition, or PB-UMKU is incomplete. The review must therefore ask what operating state is required for this transaction now, not merely whether an NIB exists.

For confirm the licence state for the exact transaction, the practical deliverable is a version-controlled decision row that remains usable when the activity, location, counterparty, or responsible person changes. It should connect identify the risk level and licence product shown for the activity. with check verification, effectiveness, validity, conditions, and location., then show how request sector or product approvals where the transaction requires them. and confirm that the supplied output belongs to the same kbli-location record. affect the next approval. Record the source for identify the risk level and licence product shown for the activity., the reviewer of check verification, effectiveness, validity, conditions, and location., the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

• Identify the risk level and licence product shown for the activity.
• Check verification, effectiveness, validity, conditions, and location.
• Request sector or product approvals where the transaction requires them.
• Confirm that the supplied output belongs to the same KBLI-location record.

Document uncertainty and obtain competent advice rather than inferring permission from the NIB title.

Official References and Review Basis

Primary materials for How to Validate an Indonesia NIB Before Relying on a Company 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 How to Validate an Indonesia NIB Before Relying on a Company.

• OSS NIB search : Official public field for searching a business operator by NIB number.
• AHU company profile search : Official search for Indonesian limited-liability-company profile data.
• Government Regulation No. 28 of 2025 : Current risk-based business licensing framework; it revoked Government Regulation No. 5 of 2021.
• 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.

Regulatory Notes and Limitations

How to Validate an Indonesia NIB Before Relying on a Company 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 How to Validate an Indonesia NIB Before Relying on a Company, 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 How to Validate an Indonesia NIB Before Relying on a Company, oSS workflow screens and document labels should be checked at execution because system implementation and transition treatment can change.
• For How to Validate an Indonesia NIB Before Relying on a Company, a government-issued record does not replace tax, corporate, bank, premises, product, or sector evidence that another authority or counterparty may require.

Close the counterparty and payment identity loop

The final step compares the NIB owner with the contracting party, invoice issuer, tax identity, bank-account beneficiary, delivery party, and communications domain. Differences should be explained by a documented legal or commercial relationship before payment.

NIB validation is not a credit assessment or guarantee of performance. It is one control within a broader due-diligence file that should also address ownership, sanctions, references, capacity, quality, cybersecurity, and contractual remedies as relevant.

For close the counterparty and payment identity loop, implementation should convert this stage into a dated control record rather than a conversation summary. It should connect match the contract, purchase order, invoice, and bank beneficiary. with confirm tax and address data where the transaction requires it., then show how record the goods, service, location, and maximum approved exposure. and set refresh triggers for changes, expiry, adverse events, or long contracts. affect the next approval. Record the source for match the contract, purchase order, invoice, and bank beneficiary., the reviewer of confirm tax and address data where the transaction requires it., the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

• Match the contract, purchase order, invoice, and bank beneficiary.
• Confirm tax and address data where the transaction requires it.
• Record the goods, service, location, and maximum approved exposure.
• Set refresh triggers for changes, expiry, adverse events, or long contracts.

Place the validated entity and licence data inside the commercial approval file so procurement and finance use the same counterparty identity.

Use the Indonesia company registration service scope to coordinate each deed, OSS, licensing, banking, or post-registration dependency identified for how to validate an indonesia nib before relying on a company.

Rely on the NIB only for the facts it actually proves

A valid NIB supports the identity and OSS record shown by the official source. It does not alone prove legal existence, licence completeness, delivery capacity, product approval, tax standing, ownership of a bank account, or performance of the promised contract.

Complete the loop through AHU, current KBLI scope, the required licence state, and matching transaction evidence. Record the date and boundary of the decision so future users know exactly what was checked.

Related insights

• Fake NIB and Company Registration Risks in Indonesia
• Verify Indonesian Company Documents Before Payment
• Choosing KBLI Codes for PT PMA Registration