Blog

Building a CFDI 4.0 Invoicing SaaS for Mexico

2026-03-10·7 min
SaaSFintechNext.js

If you've ever dealt with Mexican tax compliance as a developer, you know the pain. CFDI 4.0 (Comprobante Fiscal Digital por Internet) is Mexico's mandatory electronic invoicing standard, and building a platform around it is... an adventure.

Here's what I learned building Eqidis from the ground up.

The Problem

Most invoicing software available to Mexican SMBs is either: - Legacy desktop apps that feel like they're from 2005 - Enterprise solutions priced for corporations, not small businesses - Generic accounting tools that bolt on CFDI support as an afterthought

We saw an opportunity: build a modern, web-first invoicing platform that treats CFDI 4.0 as a first-class citizen, not a plugin.

The Tech Stack

The choice of Next.js was deliberate. Server Components let us render invoice previews server-side (critical for PDF generation performance), while Client Components handle the interactive dashboard experience.

The Hard Parts

1. SAT Integration

Mexico's tax authority (SAT) has specific XML schemas, digital seals (CSD certificates), and PAC (Authorized Certification Provider) requirements. Every invoice must be:

  1. Generated as XML following the exact CFDI 4.0 schema
  2. Digitally signed with the issuer's certificate
  3. Sent to a PAC for validation and stamping (timbrado)
  4. Stored with the UUID assigned by SAT

Getting this right meant parsing X.509 certificates in the browser, building XML serialization that SAT's validators accept, and handling the async PAC stamping flow gracefully.

2. PDF Generation at Scale

Every invoice needs a PDF representation. We built a custom renderer that takes the CFDI XML data and produces clean, branded PDFs. The trick was keeping it fast — pre-rendering templates server-side and caching common layouts.

3. Bank Statement Converter

One feature users love: upload a bank statement PDF, get an Excel file with categorized transactions. This involved PDF parsing, pattern recognition for different bank formats, and a clean mapping UI.

Architecture Decisions That Paid Off

Subscription-first billing. We built plan management and usage tracking from day one. This let us offer a generous free tier while maintaining clear upgrade paths.

Multi-tenant from the start. Row-level security in PostgreSQL means every query is automatically scoped. No data leaks, no "oops, wrong customer" bugs.

Modular invoice templates. Instead of hardcoding invoice layouts, we built a template system. New invoice types (notas de crédito, complementos de pago) plug in without rewriting the renderer.

What I'd Do Differently

  1. Start with PAC integration tests earlier. We burned days on XML formatting bugs that only surfaced during PAC validation.
  2. Build the onboarding flow before the features. Users need to upload certificates and configure their fiscal data before they can invoice. We built invoicing first and onboarding second — backwards.
  3. Invest in error messages. SAT returns cryptic error codes. Translating those into actionable user messages was underestimated work.

The Result

Eqidis now handles invoicing for dozens of Mexican businesses, from freelancers to small manufacturers. The platform processes invoices in seconds, and users consistently tell us it's the first invoicing tool they don't hate using.

If you're building for the Mexican market — or any market with complex tax compliance — the key insight is: treat compliance as a product feature, not a technical constraint. Your users are drowning in bureaucracy. Make it disappear.

All posts