Indonesian finance teams running Odoo usually end up with two parallel invoicing processes. The customer invoice is posted in account.move, and then somebody re-keys the same transaction into a separate e-Faktur workflow — matching tax identity numbers, applying the correct serial number range, restating tax bases in rupiah, and producing the file the tax application expects. Odoo core has no concept of an Indonesian tax invoice serial number, no field for a counterparty NPWP or NIK at the level the regulator expects, and no export that matches the required record layout. The result is duplicated data entry at month end, mismatches between the general ledger and what was reported, and a correction process that lives in spreadsheets and email rather than in the ERP.

ECOSIRE builds a dedicated Odoo module that makes the e-Faktur obligation a property of the invoice itself. We extend account.move and account.move.line with the Indonesian tax fields — counterparty tax identity, transaction and additional codes, replacement/correction flags, the assigned serial number and the reported status — and add a new model for serial number ranges so a controller can register an allocated block, watch consumption, and be blocked by an @api.constrains guard before a range is over-drawn or a number is issued twice. Serial assignment happens inside an overridden _post(), so the number is bound to the same database transaction that creates the journal entry: an invoice can never be posted without a number, and a number can never be consumed by an invoice that failed to post. Tax treatment is driven from your existing master data — account.tax, fiscal positions and product categories carry the Indonesian classification, so the right answer falls out of the normal sales flow instead of being chosen by hand at export time.

One posting produces both outputs. The human-readable tax invoice is a QWeb report you can brand and then print or email through the standard mail.template and chatter flow, and the machine format is produced by a dedicated export model that assembles the header and detail records, validates them field by field, and writes the file for upload. Validation runs before the file is written, not after it is rejected: tax identity format, mandatory address and unit-of-measure data, base-versus-tax arithmetic to the rupiah, and period boundaries are all checked, with each failure reported against the specific invoice so a batch can be fixed in one pass. When the tax application rejects a document, the correction workflow creates a properly linked replacement — the new invoice records the original serial number and the correction sequence, the original is flagged, and both stay joined in Odoo so the trail still reads correctly months later. Every generated file, its checksum, its line count and the user who produced it are retained as ir.attachment records on the export, and access is governed by ir.model.access.csv plus record rules so only the tax role can allocate serials or regenerate a submitted batch.

The module is delivered for your exact Odoo version — 17.0, 18.0 or 19.0 — and runs on Community as well as Enterprise, because the __manifest__.py depends only on the account app rather than on any Enterprise-only accounting feature. Where you do run Enterprise we can wire the export into an automated action or a scheduled ir.cron job so a batch is assembled on a fixed day each month, and every method is reachable over XML-RPC and JSON-RPC if you want middleware or a portal to trigger generation externally. Multi-company groups get per-company serial ranges and per-company numbering that respect the standard company record rules.

This is a build-to-order product, not a download. After you request a quotation we hold a short scoping call to confirm your Odoo version and edition, your current tax configuration, whether you invoice from one company or a group, and how you want corrections handled. We come back with a fixed scope and a fixed quote, then build it, test it on a copy of your database, and hand it over. Typical delivery is two to four weeks from confirmed scope, and you receive the full source, a git repository, documentation, training and a post-go-live support window — not a black box.