Indonesia Customs Registration: Business Data and Access Preparation Checklist

Choose the customs capacity before collecting files

For routine importer or exporter preparation, start with the Business Identification Number (Nomor Induk Berusaha, NIB) issued through Online Single Submission (OSS). DJBC’s current registration guidance says importers and exporters are treated as having registered when they hold an NIB functioning as the relevant company registration, importer identification and customs access. It separately directs customs brokers (PPJK), carriers and free-trade-zone operators to the CEISA 4.0 application route. Confirm the capacity rather than assembling every category’s documents.

Write the intended capacity at the top of the preparation file, alongside the entity name and the person coordinating the checks. A company importing its own goods and a business acting as a customs broker have different tasks. Choose the access category before choosing the document list.

The underlying entity records should already be available from company registration in Indonesia . Retrieve the latest corporate records for comparison, rather than relying on the first incorporation folder. A subsequent change of address or director can make an otherwise genuine old copy unsuitable for preparing current data.

Complete the business-data comparison sheet

For Indonesian customs registration, prepare the eight data groups specified by Article 9 of PMK 219/PMK.04/2019 : NIB, NPWP, business identity and address, responsible-person identity and address, KBLI, business legal status, capital, and Indonesian or foreign workforce counts. Article 4 also requires valid taxpayer-status information (KSWP). The comparison sheet below adds practical evidence checks; it is an internal preparation tool, not a government form or a universal upload list.

Add a short discrepancy ticket for every failed row: field name, conflicting values, source dates, correction owner and evidence needed to close it. Keep the original values visible until resolution; overwriting the worksheet can hide what actually changed. The owner should distinguish a genuine difference, such as two locations, from an outdated record.

Supporting files should explain the data being compared. Do not interpret this table as a demand to upload every deed, identity document or personnel record into CEISA. Follow the actual requirements of the chosen access category and the current system prompt.

Prepare account evidence alongside this sheet: the authorised user, recovery control and a dated login rehearsal. These are separate company checks, not additional business-data fields. The records join at handover, so a completed comparison sheet should not hide an unresolved access problem.

Check identifiers and account control separately

Use current identifiers rather than copying an old registration screenshot. Bea Cukai’s NPWP transition notice states that CEISA 4.0 services use 16-digit Taxpayer Identification Numbers (NPWP) from 1 January 2025 and asks users to adjust NPWP and Nomor Identitas Tempat Kegiatan Usaha (NITKU). Confirm the company and relevant business location against their current records; do not guess the NITKU from an address.

Open the official CEISA 4.0 portal and establish whether the company already has a usable account before creating another registration request. The public entry point provides registration and account-recovery options. Exact screens and permissions depend on the account and service, so record what your authorised user can actually reach.

Treat company-controlled recovery as a preparation requirement you set internally. A consultant’s successful login does not demonstrate that the company can recover the account after a staff or service-provider change. Make the following checks with the authorised account holder:

• Identify the named user and the company for which that person will act.
• Confirm access to the registered email and the available recovery channel.
• Record who approves user access and how departing users will be removed or replaced.
• Check that the displayed company identity and needed service match the preparation file.

Route each failure to its owning record or support channel

A difference between systems needs a diagnosis before another submission. DJBC says customs registration data integrates with OSS NIB and Directorate General of Taxes NPWP data. Its data-maintenance guidance requires users to keep those source records current. Compare the source first, then the customs display; repeatedly changing the same value in several places can make the discrepancy harder to explain.

When a user cannot register a portal account, the official CEISA continuity instructions give a conditional support route: a request signed by the company’s responsible person, submitted through CEISA CARE. The listed information includes NPWP and NITKU, the user’s full name, telephone, email and username. Prepare that information if this failure occurs; the contingency is not a blanket instruction to bypass normal registration.

For an existing block, a password reset is not evidence that the restriction has been removed. PMK 219 treats blocking and unblocking as a separate process. Preserve the actual notice and resolve its stated cause instead of describing every access problem as an activation delay.

Rehearse the handover and retain observable evidence

Run a short rehearsal with the person who will use the preparation pack. The purpose is to prove that the evidence can be found and the intended account can be used, without submitting a dummy customs declaration or inventing a transaction. This is an internal acceptance exercise, not an official approval.

1. Open the current company record set and identify the NIB, tax identifier and applicable customs-access evidence.
2. Have the authorised user sign in through the official portal and confirm the displayed company.
3. Check the required service or module within that user’s permitted access, recording any unavailable function.
4. Package the comparison sheet, closed discrepancy tickets and dated access-check result for the filing team.

For each check, record the date, operator, result and evidence location. Use redacted screenshots where useful, and keep full identity records in an appropriately restricted folder. A saved login screen is not proof of completed customs registration. Access evidence must correspond to the company’s capacity; Article 12 of PMK 219 distinguishes the qualifying NIB and the applicable category approvals.

If the next decision is whether to schedule goods movement, NIB registration and activation checks should be completed against the intended shipment. A preparation pack supports that review; it does not clear a shipment, establish product eligibility or calculate import taxes.

Use the handover to expose dependencies rather than promise a fixed completion date. State which checks are complete, which remain pending and who must act. A support-ticket acknowledgement proves that an issue was reported, while a corrected displayed record or relevant approval provides different evidence.

Release the customs preparation pack by exception status

Hand the pack to the filing team when every data group has a supported result and the account rehearsal shows usable, authorised access for the intended company and task. Mark any genuinely inapplicable item with a reason. Keep a hold on unresolved identity, taxpayer-status, responsible-person or access-category conflicts.

If a source correction is complete but the customs system still differs, hand over the open ticket as an unresolved dependency, not as a completed check. The decision is whether the team has reliable inputs and controlled access for its next task; shipment approval remains a separate decision.