Japan's Qualified Invoice System changed what a valid invoice actually is. A buyer can only claim input consumption tax when the seller's document carries the seller's registration number, states the taxable amounts separated by rate (10% standard and 8% reduced), and shows the consumption tax per rate — with rounding applied once per rate per invoice, not per line. Finance teams discover the gap the same way every time: a customer's AP department rejects an invoice because the registration number is missing or the 8% items were folded into the 10% subtotal, and the ERP has no clean way to reissue a compliant correction that references the original document. Odoo core gives you account.move, tax groups and a QWeb invoice report, but it has no concept of a qualified-invoice registration number on a partner or company, no per-rate rounding policy, no rejection-and-correction lifecycle, and no retention rules tied to Japanese record-keeping expectations.

We build a dedicated addon that installs alongside your existing chart of accounts and does not fork core accounting. On the data side we extend res.company and res.partner with a validated registration number field (format-checked through @api.constrains, so a malformed number can never reach a posted document), and we extend account.move with computed fields — declared with _inherit on models.Model, not new tables — that group the move's line_ids by tax rate and produce a per-rate taxable base, per-rate tax amount and a single rounding decision per rate. Those computes are @api.depends on the invoice lines and their taxes, so the breakdown recalculates deterministically and stores on the move for reporting. Tax mapping comes from your existing master data: it is driven off account.tax records and fiscal positions rather than hardcoded rates, so a future rate change is a configuration change, not a code change.

Output is generated once and rendered twice. A single posted move produces the human-readable qualified invoice as a QWeb PDF (a proper report_action with its own restylable template showing the registration number, the per-rate blocks and the retained document identifier), and the same computed values feed a machine-readable payload — CSV, JSON or a structured XML shape agreed during scoping — exposed on the model so downstream systems, a portal or an integration can pull it over XML-RPC/JSON-RPC without re-deriving the numbers. That single-source rule is what keeps the paper and the data from drifting apart, which is the failure mode that turns a routine audit into a reconciliation project.

Rejections get a real workflow instead of a spreadsheet. When a customer's AP rejects a document, an authorised user records the rejection with a reason on the invoice; the module drives a correction path that issues either a credit note plus a replacement or an amended qualified invoice, always carrying a reference back to the original document number so the chain is reconstructable. Every state change is stamped into the chatter through the standard mail.thread mixin, and the archive side keeps the issued PDF and its payload as protected ir.attachment records with a retention marker, so a routine attachment cleanup cannot quietly remove evidence. Access is governed properly — ir.model.access.csv entries plus record rules, so an invoicing clerk can issue and correct while only a finance manager can override a registration number or release an archived document — and scheduled ir.cron actions flag posted moves missing a counterparty registration number before month-end close.

This is build-to-order, so nothing here is a download you install this afternoon. We start with a scoping call to look at your actual chart of accounts, tax configuration, invoice templates, customer requirements and Odoo version, then quote a fixed scope. Typical delivery is two to four weeks from confirmed scope. You get the module built against your exact version — Odoo 17.0, 18.0 or 19.0, Community or Enterprise (the Enterprise build can hook into the accounting reporting engine and follow-up flows where you use them; the Community build ships the same compliance logic through standard views and QWeb) — installed on a staging database first, run through UAT with your own invoices, then deployed to production with a rollback plan and a support window while your first real billing cycle goes out the door.