Company Establishment in Indonesia: Legal Approval and Initial Registration Tasks

Agree the formation record before the deed

Settle the intended owners, business activities and Indonesian address before the notary turns those decisions into a deed. The ordinary PT route is the focus here. Foreign investment introduces a PT PMA review, including activity-specific ownership and capital conditions; a domestic structure should not be selected simply because it appears quicker. The broader company registration requirements in Indonesia place entity choice and activity planning ahead of the filing sequence.

Create a single, dated formation record for the founders and the notary to approve. Record the proposed name, registered domicile, detailed address, intended activities, share allocation, capital categories, directors, commissioners and beneficial-owner information. Attach the identity and authority documents behind those entries. For a corporate shareholder, identify who can authorise its investment and sign; do not infer authority from a person’s job title.

Treat the agreed formation record as your comparison copy. Ask the notary to identify any field that cannot be filed as proposed, and settle that point before signatures. Names should follow the accepted identity documents; abbreviations, translated names and address variants should have an agreed treatment. Keep the final version alongside the deed draft so that a later amendment is distinguishable from a typing correction.

For planning, HSJGlobal’s registration page gives a roughly two-to-four-week allowance after complete documents are accepted. Read this as approximately 14–28 calendar days for the registration stage, not an official deadline from the first enquiry to trading. Preparation before acceptance, additional licences, bank onboarding and immigration are separate dependencies. A useful project plan therefore states its start condition and the exact documents expected at its end.

Obtain and check the AHU approval file

The filing owner should be able to show how the agreed inputs became the signed deed and then the official approval output. AHU’s published workflow uses a notary login, a payment voucher, company-data entry, review, deed upload and confirmation before the approval can be downloaded. Its fields cover domicile, activities, capital, management, shareholders and beneficial ownership. These are filing instructions, not a substitute for checking the legal eligibility of the proposed structure. The official AHU workflow is the source for that sequence.

1. Confirm the filing scope with the notary: which deed, company name and applicant will be used, and what documents or signatures remain outstanding.
2. Approve the preview against the agreed record before final confirmation; request correction of an input error at that stage.
3. Retain the payment evidence and application receipt, then obtain the final downloadable AHU approval and the signed deed copy.
4. Compare the approved company identity, deed reference and dates; log any difference and obtain a documented response from the notary.

A receipt proves that a filing was made; it does not replace the issued approval. Store both, but label them differently. An unsigned draft, a portal preview and an issued output should never share the same “final” filename. Keep the original downloaded file alongside any working translation, and record who supplied it and when.

The approval file then becomes the reference for initial tax and OSS work. Prepare the contacts and supporting material while the notarial work proceeds, but do not guess an approval number or date to complete another application. The next registration owner should receive verified source documents, not a collection of screenshots without context. That dependency explains why the two registration tracks can share preparation while still needing separate acceptance tests.

Carry the approved identity into tax and OSS registration

First establish whether the company tax record already exists through the formation channel. AHU’s instructions describe NPWP generation after approval, and DGT’s corporate-registration manual recognises registration through AHU as well as Coretax. Check for an existing NPWP before starting a separate registration. This is a check against duplicate work, not an assumption that integration has successfully completed in every case.

Where a separate corporate application is needed, DGT’s Coretax corporate registration manual describes New Registration → Corporate, followed by the entity category and any representative details. It validates the approval reference against AHU and covers contacts, responsible persons, economic data, address, formation documents and the declaration before submission. Use that official manual as a field checklist; screen wording can change. Retain the submission reference and inspect the resulting tax registration documents.

Give the company access to the account and an identified responsible person. Confirm that the company name, approval reference and address agree with the accepted formation file, and record who receives notifications. A tax number copied into a spreadsheet is less useful than a verified record with working access. Tax classification and filing obligations require a separate review of the company’s activities and status; this initial task does not settle every future return.

Review OSS outputs by activity and location

For Online Single Submission (OSS), prepare the company identity and intended activities using the relevant Klasifikasi Baku Lapangan Usaha Indonesia (KBLI) codes, together with the project locations and supporting information requested by the current workflow. Check what has actually been issued: the Business Identification Number (NIB), its activity information, and the status of any additional licensing tasks. Save the downloadable documents and the corresponding status evidence.

Do not close the licensing task merely because an NIB has arrived. OSS publishes a distinct Standard Certificate verification workflow for the responsible ministries and agencies. Where that verification or another approval applies to your activity, record it as an unresolved launch dependency until the required status is evidenced. Check premises and supporting approvals in the same activity-specific review; a registration checklist should not declare every business ready to operate.

Test the establishment handover against the evidence

Accept the establishment work against evidence, rather than counting the number of PDFs delivered. The register below is a practical control tool, not an additional government form. It combines the AHU application-to-approval distinction, DGT’s validation of company identity, and OSS’s separate verification workflow into tests a founder can apply at handover.

Add a document location, reviewer, check date and next action to each row in your working copy. Use three plain statuses: accepted, correction required, or outstanding. An outstanding sector approval need not erase the existence of an accepted AHU file, but it must stay visible to whoever decides whether the planned activity can begin. Conversely, an NIB should not be used to excuse a missing legal-entity approval copy.

Ownership here means responsibility for obtaining and checking the evidence, not power to approve it. A service provider can coordinate submissions; the relevant authority makes the official decision. The division of responsibilities across registration authorities helps route an unresolved issue to the right participant. The register then gives the directors a single view of what has been delivered and what remains dependent on an outside decision.

At handover, ask the incoming administrator to locate a document using the register and open the relevant account. This simple practical test exposes inaccessible folders, personal email dependencies and missing recovery details while the filing team is still available. Retain an access inventory and permission record without circulating passwords in the document pack.

Repair mismatches before they reach the next system

Repair the earliest incorrect record before copying the error into another system. Start by identifying whether the source document is wrong, the submitted data are wrong, or the downstream system has not reflected accepted data. Those are different problems. A notarial correction, a portal data change and a synchronisation enquiry should not be treated as interchangeable tasks.

1. Isolate the mismatch. Record the two conflicting entries, their document references and the business action they are blocking; avoid vague descriptions such as “registration problem”.
2. Identify the authoritative input. Compare the signed deed, issued approval and accepted identity documents, then ask the filing owner to confirm the correction route.
3. Preserve the application trail. Keep the original submission, official correction request, revised file and response together so the reviewer can follow the change.
4. Recheck connected outputs after resolution. Confirm which tax or OSS entries need a further update, and record completion separately for each affected system.

For example, if a contact detail belongs to an agent rather than the company, resolve control of the contact and notification route without assuming that every issued document must be replaced. If the wrong business activity was approved, changing a description in a later application is not a reliable repair. Pause the affected work and have the notary and licensing owner establish which underlying records require amendment.

Use a specific correction owner and next check date for every open item. Where an authority asks for further evidence, answer the actual request and retain its reference. Do not repeatedly submit different versions through different accounts in the hope that one will be accepted. If responsibility is disputed, escalate with the source documents and submission history; an unexplained “pending” label is not an actionable handover.

Release the company for its next task only when the evidence agrees

Release the formation file to the next team when the deed and AHU approval agree, the initial tax and OSS outputs have been checked, and every unfinished dependency has an owner. That is an evidence-based establishment handover. Release a proposed commercial activity only after its applicable licensing and premises conditions have been reviewed and the required outputs are available.

Prioritise the oldest unresolved identity or approval issue because it can affect the later registrations. Escalate an unexplained inconsistency, missing approval, unverified licensing condition or inaccessible account before promising a launch date. Keep the accepted records and open-task register together so the directors can distinguish company establishment from the separate decision to start operating.