I volunteered to build the thing every engineer avoids: integrating with a Latin American tax authority.
LATAM e-invoicing nobody wants to build
I volunteered to build the thing every engineer avoids: integrating directly with a Latin American tax authority.
Government e-invoicing is where optimism goes to die. Costa Rica's Hacienda and Mexico's CFDI don't hand you a clean OpenAPI spec. You get XML schemas, digital-signature requirements, certificate handling, and rejection codes that are terse on a good day. There's no move-fast-and-break-things here. A broken invoice is a legal document that failed to file.
So I built a shared fiscal engine that handles it. Canonical invoice input, integer money, jurisdiction resolution so one core serves multiple countries, and the certificate and submission flow that actually satisfies the regulator. Around 230 tests guard it, because the feedback loop with a tax authority is measured in "your business is now non-compliant."
Here's why it matters as a hiring signal. I walk toward the hard, high-stakes integrations instead of around them. That's where the real product value hides, and it's where most teams are understaffed.
Building anything that touches invoicing or compliance in Latin America? Ask me what makes these APIs brutal. I've got the scar tissue.