AC Billing: Costa Rica Electronic Invoicing
A multi-tenant billing platform that issues Costa Rican electronic invoices, signs them with XAdES-EPES, submits them to Hacienda v4.4, and reconciles every status change.
An electronic invoice is a legal document with a schema attached. In Costa Rica it has to be signed, submitted to Hacienda, accepted, and traceable long after the sale. A rejected invoice can stop a shipment. A lost acceptance can break the books.
AC Billing treats the invoice as a fiscal object first and a screen second. The code is complete and verified, including the full fiscal pipeline; the product is in beta while the production deployment configuration is finished.
The Problem
Most billing tools force a bad choice. Generic invoicing ignores the local schema. Enterprise suites are too heavy for a counter clerk who has thirty seconds per customer. The result is duplicated entry, invoices issued outside the system, and a fiscal history that cannot be reconstructed.
The requirement was a counter flow an operator can run without training, backed by a fiscal pipeline that never guesses.
The Approach
Python 3.12 and FastAPI for the API, Celery for asynchronous fiscal work, PostgreSQL 16 with row-level security per tenant, Redis, and a Next.js 15 BFF so no API token reaches the browser. Money is Decimal only: 10 decimal places internally, Hacienda's precision at emission, one ROUND_HALF_UP at the XML boundary.
A separate fiscal worker owns XAdES-EPES signing, submission, status polling, reconciliation, and contingency. Every state change lands in an append-only fiscal_events table, which is what makes a rejected or retried document explainable later. The schema is 50 idempotent SQL migrations applied under an advisory lock, with a checksum ledger.
The UI has two profiles over one domain: a counter view for issuing and a back office for clients, products, and fiscal status.
The Outcome
Code complete and beta. The suite holds 1,578 backend tests plus 61 frontend tests. All 50 migrations apply twice on a clean database, the ten-container stack reports healthy, and the fiscal pipeline was verified against sandbox submissions. Production deployment needs two configuration items, a production identity provider and the final environment values, before the first real invoice.
Key Takeaway
Fiscal software is a correctness problem before it is a UX problem. If the XML is wrong by a cent, the business stops selling.
Ready to Build Your Platform?
One 30-minute call to see if I'm the right fit. No pitch. No pressure. In English or Spanish, just a conversation about what you need to build.
Every engagement is scoped and quoted individually. There is no rate card, and no price before I understand the system. The first step is a 30-minute call, in English or Spanish; you leave it with a clear read on scope, sequence, and what the work would take.