Since Japan's Qualified Invoice System took effect, a sales document is no longer just a sales document. To let your customer claim input consumption tax, the invoice you issue has to carry your qualified invoice issuer registration number, break out taxable amounts and consumption tax by rate (the 10% standard rate and the 8% reduced rate must be shown separately, not merged into one tax line), and identify issuer and recipient in a form that survives inspection. ERPNext out of the box gives you Sales Invoice, Sales Taxes and Charges Template, and a print format — none of which know what a registration number is, none of which enforce per-rate subtotalling, and none of which stop a user from submitting an invoice to a Japanese customer using a template that quietly blends two rates into a single row. Finance teams patch the gap with a spreadsheet and a hand-edited PDF, which is exactly where audit findings come from.

We build a proper Frappe app — its own repository, its own module, installed with bench get-app and bench --site <site> install-app — rather than a pile of untracked customisations on your production site. The app adds a Japan Qualified Invoice Settings single DocType holding your registration number, issuer legal name and address, rate-to-account mapping and numbering policy, plus a Japan Qualified Invoice DocType generated from a submitted Sales Invoice through an on_submit handler registered in hooks.py doc_events. Custom Fields shipped as fixtures put the customer's registration number on Customer and a tax classification (standard, reduced, exempt, out-of-scope) on Item and on Sales Taxes and Charges rows, so mapping is driven by ERPNext master data rather than by whoever is typing that day. A server-side validator runs before submit: it refuses a document whose tax rows cannot be resolved to a declared rate, whose per-rate consumption tax does not reconcile to the grand total within the permitted rounding rule, or whose issuer registration number is missing or fails checksum. A Client Script surfaces those errors in the form instead of as a stack trace.

One posting produces both outputs. The human-readable qualified invoice is a Jinja/HTML Print Format that renders correctly in Japanese with your logo and seal, covering the statutory particulars — issuer name and registration number, transaction date, description of goods or services with reduced-rate lines flagged, taxable amount and consumption tax per rate, and the recipient's name. The machine format is a structured payload generated by the same posting, so the PDF your customer files and the record you keep can never disagree; it is emitted through a whitelisted method (@frappe.whitelist()) callable over the Frappe REST API, so a portal, an e-invoicing connector, or your customer's AP system can pull it without re-keying. Corrections follow Japanese practice rather than a cancel-and-reissue: a rejection or dispute is captured on the document, an amendment is raised referencing the original invoice number, returns and credit notes are issued as corrected-return documents (適格返還請求書) linked to the invoice they adjust, and the original is never silently overwritten.

Permissions are wired as Frappe role profiles rather than field-level guesswork: an Accounts User raises and submits, a designated compliance role amends or cancels a qualified invoice, and the registration-number settings are restricted so nobody changes issuer identity mid-year without leaving a trail. Scheduler events handle the periodic work — a daily integrity and completeness check across the period's invoices, and a monthly reconciliation that ties the qualified invoice register back to the ERPNext General Ledger, so the consumption tax you reported is the consumption tax you posted. Documents are versioned and archived for your retention period, and the integrity check flags a gap before an auditor does. The app targets Frappe/ERPNext v15 and v16 and is built against your actual version, so you are never waiting on someone else's compatibility release.

This is a build-to-order product, not a marketplace download. Nothing ships until we have talked to you: a scoping call establishes your rate mix, whether you handle reduced-rate items, how customers want to receive documents, your retention obligation, and any existing print formats we must preserve. From confirmed scope, typical delivery is one working week — build, unit tests on a staging bench mirroring your version, UAT with your own real invoices, then a production install behind a documented rollback. You receive the git repository, so the code is yours to read, fork and keep running whether or not you renew support with us.