Project Context
Companies with recurring billing often end up "making do" on Japan's Invoice System and Electronic Books Preservation Act requirements using spreadsheets and manual process rules. VAON built an on-premises invoice and contract management system in-house: one ledger running contract to invoice to payment reconciliation to reminder, deployed entirely inside the customer's own server with the only outbound traffic being email. All 15 legal requirement items were verified by measuring the running system, not by checking implementation on paper.
Challenges
Locking a confirmed invoice against edits has to coexist with the law's requirement to preserve correction history
Japan's Electronic Books Preservation Act requires that corrections and deletions of transaction data be traceable. Simply banning edits after confirmation breaks the real workflow when a mistake is found. A confirmed invoice had to stay unchangeable while still offering a legitimate path to a corrected state.
Application-layer logging alone misses direct SQL operations
Recording correction and deletion history only in application code leaves direct database operations unlogged. Under audit or tax inspection, being asked whether operations bypassing the app are also captured is a question application-layer logging cannot answer on its own.
Meeting a 3-second search requirement without cloud-scale headroom
The Electronic Books Preservation Act requires search by transaction date, amount and counterparty, with range and combined-field queries, within 3 seconds. Running on the single server the customer provides on-premises meant the design could not assume elastic capacity the way a cloud service can.
Shipping source code creates a risk that customer-side changes break legal requirements
A buy-once model with full source code delivery avoids vendor lock-in, but it also means tax calculation, audit logging and invoice confirmation logic could be broken unintentionally when the customer or another vendor modifies the code.
VAON's Solution
Designed the system around one ledger flowing counterparty to contract to invoice to payment reconciliation to reminder, rather than a standalone invoice-issuing tool.
Made confirmed invoices immutable and unremovable. Corrections go through a reasoned reversal ("red-ink" cancellation) followed by reissue; the original PDF is never touched, and the cancelled-state display is generated as a separate file so the original's hash never changes.
Recorded correction and deletion history with database triggers across the six evidentiary tables. Because the trigger sits below the application layer, direct SQL operations are captured in the same history, not just calls made through the app.
Met the search requirement through index design rather than adding a separate search engine, staying inside PostgreSQL's standard capabilities — verified with EXPLAIN that a 10,000-row dataset for both contracts and invoices resolves via index scan — and kept the overall architecture to six components (Web, API, Worker, PostgreSQL, object storage, Nginx) with no additional middleware such as Redis, so the customer's IT team has fewer moving parts to operate and fewer failure points.
Restricted all outbound network traffic to email (SMTP). Searched the entire source tree for external-service credentials and confirmed the only environment variables present are the six SMTP-related ones — no dependency on cloud storage, external payment, external auth, or a generative-AI API.
Protected the code paths tied to legal requirements — tax calculation, audit logging, invoice confirmation — with automated tests, so that a customer-side modification breaking one of them fails the test suite.
Value Delivered
List and detail screens respond in under 100 ms at p95, well inside the 3-second requirement
The 100-row list screen measured p50 3 ms / p95 87 ms; the detail screen measured p50 2 ms / p95 83 ms. Against a 3-second requirement, the measured p95 sits at roughly 1–3% of the allowed time.
Searching 10,000 records completes in 0.075–0.371 ms
Searching by transaction date, amount and counterparty across a 10,000-row dataset for both contracts and invoices completed in 0.075–0.371 ms. EXPLAIN confirmed an index scan is used, so the margin should hold as record counts grow.
50 concurrent users, 1,645 requests in 30 seconds, zero errors
A load test with 50 sessions logging in simultaneously and cycling through invoice list, detail, amount-range search and contract list — an operation sequence matched to real accounting workflow — processed 1,645 requests in 30 seconds with zero errors.
All 15 legal requirement items verified by measurement, not implementation review
The 7 Invoice System line-item requirements and 8 Electronic Books Preservation Act requirements for electronic transaction data were each checked against actual system behavior. Both the verification results and the method used are delivered as a compliance checklist.
The only outbound traffic is email — internal SMTP is enough to run with no internet connection
A search of the entire source tree for external-service credentials turned up only the six SMTP-related environment variables. There is no dependency on cloud storage, external payment, external authentication, or a generative-AI API.
Technology Stack
