Indonesia Pre-Operation License Gate: Evidence to Approve First Revenue

An Indonesian company should approve first revenue only when the legal entity, KBLI, project location, risk-based licence product, verification, supporting approvals, tax and invoicing setup, contract, delivery process, and evidence owner all support the same transaction. Government Regulation No. 28 of 2025 requires the relevant business licence for the activity; an NIB alone is not a universal permission to operate.

Build the gate around the first real transaction rather than a generic company checklist. The product or service, customer, location, delivery method, payment flow, regulated features, and use of staff or facilities can change the required evidence. A failed gate should produce a narrow stop condition and remediation owner, while unrelated activities remain governed by their own approved licence state.

First-revenue licence gate decision controls

Use the control, evidence, and release condition together; no single document should carry more meaning than it actually proves.

Key takeaways

• Do not test licences until the first transaction is specific enough to map.
• Block any component that lacks a supportable activity and project mapping.
• Release only when mandatory licence and verification states are effective.
• Do not issue the first invoice until transaction controls pass together.
• Approve a defined transaction and schedule immediate post-launch verification.

In this article

• Define the transaction
• Map activity and projects
• Prove licence effectiveness
• Test transaction controls
• Official References and Review Basis
• Regulatory Notes and Limitations
• Approve and monitor launch
• Release first revenue from transaction-level licence evidence

Define the first revenue transaction

A supportable decision begins when the company can describe the customer promise, deliverable, location, invoice, payment, people, assets, and subcontractors. For define the first revenue transaction, the live OSS output, not a generic description of the system, determines which activity, project, licence state, condition, and follow-up record needs attention.

A broad company description can conceal the activity that actually generates regulatory exposure. A reviewer should trace draft contract and scope and invoice and payment model to current authoritative records and actual operating evidence, rather than a copied template, provider promise, or unexplained portal label.

For define the first revenue transaction, operational ownership matters here because the same fact may be presented differently in corporate, licensing, tax, bank, contract, and site records. It should connect draft contract and scope with invoice and payment model, then show how delivery and acceptance steps and people, assets, and locations affect the next approval. Record the source for draft contract and scope, the reviewer of invoice and payment model, the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

Test define the first revenue transaction through normal progress, delayed invoice and payment model, and failure of delivery and acceptance steps. The normal case confirms the intended order for draft contract and scope; the delayed case states what may continue safely; and the failure case assigns the stop, correction, notification, and evidence-preservation steps for people, assets, and locations. Retain this stage-specific result with the final approval and review calendar.

• Draft contract and scope
• Invoice and payment model
• Delivery and acceptance steps
• People, assets, and locations

For define the first revenue transaction, turn the result into a controlled work item with a responsible person, due date, evidence location, escalation path, and release condition. Where this stage changes another workstream, review Indonesia Risk-Based Licensing for PT PMA Companies .

Map the transaction to KBLI and OSS projects

Before the next commitment, management should link each material component to the current KBLI and exact OSS project-location record. For map the transaction to kbli and oss projects, the live OSS output, not a generic description of the system, determines which activity, project, licence state, condition, and follow-up record needs attention.

One transaction can combine trading, services, installation, storage, or production under different requirements. A reviewer should trace kbli 2025 activity memo and oss project identifiers to current authoritative records and actual operating evidence, rather than a copied template, provider promise, or unexplained portal label.

For map the transaction to kbli and oss projects, 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 kbli 2025 activity memo with oss project identifiers, then show how location and scale data and ownership and investment screening affect the next approval. Record the source for kbli 2025 activity memo, the reviewer of oss project identifiers, the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

Test map the transaction to kbli and oss projects through normal progress, delayed oss project identifiers, and failure of location and scale data. The normal case confirms the intended order for kbli 2025 activity memo; the delayed case states what may continue safely; and the failure case assigns the stop, correction, notification, and evidence-preservation steps for ownership and investment screening. Retain this stage-specific result with the final approval and review calendar.

• KBLI 2025 activity memo
• OSS project identifiers
• Location and scale data
• Ownership and investment screening

For map the transaction to kbli and oss projects, record both the accepted position and the rejected alternatives; this prevents a later portal edit or provider message from silently changing the decision.

Prove the effective licence state

The control file must show how the company will identify the NIB, certificate, permit, verification, PB-UMKU, product, premises, and sector evidence required before performance. For prove the effective licence state, the live OSS output, not a generic description of the system, determines which activity, project, licence state, condition, and follow-up record needs attention.

An issued-looking output can remain conditional or ineffective for the intended operation. A reviewer should trace live oss outputs and verification and conditions to current authoritative records and actual operating evidence, rather than a copied template, provider promise, or unexplained portal label.

For prove the effective licence state, the practical deliverable is a version-controlled decision row that remains usable when the activity, location, counterparty, or responsible person changes. It should connect live oss outputs with verification and conditions, then show how sector and product approvals and validity and renewal data affect the next approval. Record the source for live oss outputs, the reviewer of verification and conditions, the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

Test prove the effective licence state through normal progress, delayed verification and conditions, and failure of sector and product approvals. The normal case confirms the intended order for live oss outputs; the delayed case states what may continue safely; and the failure case assigns the stop, correction, notification, and evidence-preservation steps for validity and renewal data. Retain this stage-specific result with the final approval and review calendar.

• Live OSS outputs
• Verification and conditions
• Sector and product approvals
• Validity and renewal data

For prove the effective licence state, close the stage only when the authoritative record and the operating evidence agree, or when an unresolved difference has a named owner and stop condition. For the adjacent control framework, compare Business Licenses After NIB: When a PT PMA Can Operate .

Test tax, contract, bank, and operating controls

For first-revenue licence gate, confirm the company can lawfully contract, invoice, collect, account, withhold, deliver, and retain evidence for the transaction. For test tax, contract, bank, and operating controls, the live OSS output, not a generic description of the system, determines which activity, project, licence state, condition, and follow-up record needs attention.

A licence-ready company can still fail at tax activation, invoice design, bank identity, or contractual authority. A reviewer should trace tax and invoice configuration and signatory and contract authority to current authoritative records and actual operating evidence, rather than a copied template, provider promise, or unexplained portal label.

For test tax, contract, bank, and operating controls, implementation should convert this stage into a dated control record rather than a conversation summary. It should connect tax and invoice configuration with signatory and contract authority, then show how company bank collection path and accounting and evidence retention affect the next approval. Record the source for tax and invoice configuration, the reviewer of signatory and contract authority, the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

Test test tax, contract, bank, and operating controls through normal progress, delayed signatory and contract authority, and failure of company bank collection path. The normal case confirms the intended order for tax and invoice configuration; the delayed case states what may continue safely; and the failure case assigns the stop, correction, notification, and evidence-preservation steps for accounting and evidence retention. Retain this stage-specific result with the final approval and review calendar.

• Tax and invoice configuration
• Signatory and contract authority
• Company bank collection path
• Accounting and evidence retention

For test tax, contract, bank, and operating controls, the output should name the owner, source evidence, unresolved condition, acceptance test, and the event that permits the next step.

Official References and Review Basis

Primary materials for Indonesia Pre-Operation License Gate: Evidence to Approve First Revenue 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 Indonesia Pre-Operation License Gate: Evidence to Approve First Revenue.

• Government Regulation No. 28 of 2025 : Current risk-based business licensing framework; it revoked Government Regulation No. 5 of 2021.
• Ministry of Investment and Downstream Industry/BKPM Regulation No. 5 of 2025 : Current OSS procedures, investment facilities, supervision, and reporting framework.
• 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

Indonesia Pre-Operation License Gate: Evidence to Approve First Revenue 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 Indonesia Pre-Operation License Gate: Evidence to Approve First Revenue, 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 Indonesia Pre-Operation License Gate: Evidence to Approve First Revenue, oSS workflow screens and document labels should be checked at execution because system implementation and transition treatment can change.
• For Indonesia Pre-Operation License Gate: Evidence to Approve First Revenue, a government-issued record does not replace tax, corporate, bank, premises, product, or sector evidence that another authority or counterparty may require.

Sign the release and monitor the first cycle

The responsible team should record the approval boundary, evidence, exceptions, owners, and sample review for the first contract-to-cash cycle. For sign the release and monitor the first cycle, the live OSS output, not a generic description of the system, determines which activity, project, licence state, condition, and follow-up record needs attention.

A verbal launch decision is difficult to reproduce when the activity or licence changes. A reviewer should trace signed release memo and evidence index to current authoritative records and actual operating evidence, rather than a copied template, provider promise, or unexplained portal label.

For sign the release and monitor the first cycle, the evidence file for this stage should let a new reviewer reproduce the decision without asking the original provider what happened. It should connect signed release memo with evidence index, then show how stop and escalation triggers and first-cycle sample review affect the next approval. Record the source for signed release memo, the reviewer of evidence index, the decision date, any unresolved exception, and the acceptance evidence so later changes preserve the original reasoning.

Test sign the release and monitor the first cycle through normal progress, delayed evidence index, and failure of stop and escalation triggers. The normal case confirms the intended order for signed release memo; the delayed case states what may continue safely; and the failure case assigns the stop, correction, notification, and evidence-preservation steps for first-cycle sample review. Retain this stage-specific result with the final approval and review calendar.

• Signed release memo
• Evidence index
• Stop and escalation triggers
• First-cycle sample review

For sign the release and monitor the first cycle, preserve the source record, reviewer, date, exception, and approval so another team can reproduce the decision without relying on memory.

Connect the first-revenue licence gate control to the wider Indonesia company registration workstream before committing people, travel, or funds.

Release first revenue from transaction-level licence evidence

The first-revenue gate converts a broad registration status into a test of the exact customer promise. It should show who may contract, what may be delivered, where it occurs, which licence state applies, and how the company will invoice and collect.

Approve a defined scope, preserve the evidence, and repeat the gate when the activity, location, product, customer model, or licence condition changes.

Related insights

• Business Licenses After NIB: When a PT PMA Can Operate
• Indonesia Risk-Based Licensing for PT PMA Companies
• PT PMA License Condition Tracker After Registration