Volver a Proyectos
AC Billing: facturación electrónica de Costa Rica
Tecnología Financiera
Beta

AC Billing: facturación electrónica de Costa Rica

Una plataforma de facturación multi-inquilino que emite facturas electrónicas costarricenses, las firma con XAdES-EPES, las envía a Hacienda v4.4 y concilia cada cambio de estado.

FastAPINext.jsPostgreSQLCeleryRedisKeycloakXAdES-EPESHacienda v4.4
1,578
Pruebas automatizadas
50
Migraciones
7
Contextos acotados
10
Contenedores
v4.4
Hacienda
Beta
Estado

Una factura electrónica es un documento legal con un esquema adjunto. En Costa Rica tiene que firmarse, enviarse a Hacienda, ser aceptada y quedar rastreable mucho después de la venta. Una factura rechazada puede detener un despacho. Una aceptación perdida puede romper la contabilidad.

AC Billing trata la factura como un objeto fiscal primero y como una pantalla después. El código está completo y verificado, incluido el pipeline fiscal completo; el producto está en beta mientras se termina la configuración de despliegue a producción.

El problema

La mayoría de las herramientas de facturación obligan a elegir mal. La facturación genérica ignora el esquema local. Las suites empresariales son demasiado pesadas para un cajero que tiene treinta segundos por cliente. El resultado es doble captura, facturas emitidas fuera del sistema y un historial fiscal que no se puede reconstruir.

El requisito era un flujo de mostrador que un operador pueda ejecutar sin entrenamiento, respaldado por un pipeline fiscal que nunca adivine.

El enfoque

Python 3.12 y FastAPI para la API, Celery para el trabajo fiscal asíncrono, PostgreSQL 16 con seguridad a nivel de fila por inquilino, Redis y un BFF en Next.js 15 para que ningún token de API llegue al navegador. El dinero es Decimal únicamente: 10 decimales internos, la precisión de Hacienda al emitir y un solo ROUND_HALF_UP en la frontera del XML.

Un worker fiscal separado es dueño de la firma XAdES-EPES, el envío, la consulta de estado, la conciliación y la contingencia. Cada cambio de estado queda en una tabla fiscal_events de solo adición, que es lo que permite explicar después un documento rechazado o reintentado. El esquema son 50 migraciones SQL idempotentes aplicadas bajo un lock de asesoría, con un libro de checksums.

La interfaz tiene dos perfiles sobre un mismo dominio: una vista de mostrador para emitir y un back office para clientes, productos y estado fiscal.

El resultado

Código completo y beta. La suite tiene 1,578 pruebas de backend más 61 de frontend. Las 50 migraciones se aplican dos veces sobre una base limpia, el stack de diez contenedores reporta saludable y el pipeline fiscal se verificó contra envíos de sandbox. El despliegue a producción necesita dos elementos de configuración, un proveedor de identidad de producción y los valores finales del ambiente, antes de la primera factura real.

Conclusión clave

El software fiscal es un problema de corrección antes que de experiencia de usuario. Si el XML se equivoca por un céntimo, el negocio deja de vender.

¿Listo para construir su plataforma?

Una llamada de 30 minutos para ver si soy el aliado correcto. Sin discurso de venta. Sin presión. En español o inglés, solo una conversación sobre lo que necesita construir.

Cada proyecto se define y se cotiza de forma individual. No hay tarifario y no hay precio antes de entender el sistema. El primer paso es una llamada de 30 minutos, en español o inglés; de ahí sale una lectura clara del alcance, la secuencia y lo que requiere el trabajo.

AC Billing: facturación electrónica de Costa Rica | LogicBison