Finance teams operating in South Korea carry an obligation that Odoo core has no concept of: the electronic tax invoice (전자세금계산서). Every taxable B2B supply has to be issued in the prescribed electronic form, transmitted to the National Tax Service through Hometax or an approved ASP, and retained so an auditor can reconstruct it. Out of the box, Odoo gives you account.move, a tax engine and a QWeb PDF — and stops there. There is no business-registration-number validation, no issuance state, no transmission log, no correction (수정세금계산서) workflow, and no link between an accepted NTS approval number and the journal entry it belongs to. The gap is usually filled with a spreadsheet, a second login to a portal, and a monthly reconciliation nobody enjoys.

What we build is a dedicated Odoo module that makes the e-Tax Invoice a first-class object in the accounting flow. A new model — typically ecosire.etax.document — is created when a Korean customer invoice is posted, linked one-to-one to the account.move, and driven by a proper selection state machine (draft → queued → issued → accepted / rejected → corrected). Master data does the heavy lifting: res.partner gains validated business registration number, sub-business (종사업장) code, taxation type and buyer e-mail fields, all checked by @api.constrains so a bad number is refused at data entry rather than at transmission time. account.tax records are mapped to the correct Korean classification (taxable, zero-rated, exempt) through a configurable mapping model, so the amounts on the electronic document are derived from the same tax lines the general ledger already uses — one posting, one truth, never a re-keyed figure.

Transmission is implemented against the route you actually use. We integrate with your certified ASP or direct e-tax provider over its documented HTTP/JSON or SOAP API from a Python service layer, with credentials held in ir.config_parameter rather than source control, per-company settings on res.company, and retries plus idempotency keys so a timeout can never produce a duplicate issuance. Every request and response is persisted for audit. Outbound work runs through an ir.cron queue instead of blocking the user's post action, and a mail.thread chatter entry on the invoice records each state change together with the NTS approval number when it comes back. Rejections are not dead ends: the module surfaces the provider's reason code in readable form, raises an activity for the responsible accountant, and offers a guided correction wizard (a TransientModel) that produces the correct 수정 type — cancellation, amount amendment or re-issue — linked back to the original for traceability. The same posting produces both the machine payload and a human-readable QWeb report in Korean and English, so the customer copy and the transmitted document can never drift apart.

Security and reporting follow Odoo conventions rather than being bolted on. Access is defined in ir.model.access.csv with a dedicated e-tax officer group plus multi-company record rules on company_id; the document model is append-only for accountants, and cancellation is possible only through the correction workflow. Archiving keeps the transmitted payload, the provider acknowledgement and the rendered PDF as ir.attachment records tied to the journal entry for the statutory retention period, with a searchable list view and filters by issuance status, VAT period, buyer registration number and approval number — so reconciling a period against your Hometax download is a filtered list and an export, not an afternoon. Documented model methods are callable over Odoo's XML-RPC/JSON-RPC API, so an upstream billing system or RPA bot can trigger issuance and read status without UI access. The module targets Odoo 17.0, 18.0 and 19.0, ships as a normal addon with its own __manifest__.py, depends only on account (so it runs on Community), and on Enterprise hooks into the accounting dashboard and audit trail rather than duplicating them.

This is a build-to-order product, not an existing apps.odoo.com download. After a short scoping call we confirm your Odoo version and edition, your ASP or direct-Hometax route, your chart of accounts and tax mapping, and any sub-business or multi-company structure — then we write a fixed scope. Typical delivery is one working week from confirmed scope. You get the module built and configured against a staging copy of your database first, UAT with your own invoices in the provider's test environment, a documented go-live with a rollback plan, and a post-go-live support window. The source code is handed over in a git repository you own, so nothing here makes you dependent on us to keep operating.