El framework financiero sobre Laravel.

Unos modelos Eloquent, un panel en Filament y unas cuantas reglas de negocio. Funciona. Hasta que crece, y dos años después tienes:

• Asientos que dejan de cuadrar y nadie sabe por qué.
• Módulos acoplados: tocar uno rompe otro.
• Cambios que rompen cosas en silencio, sin que CI avise.
• ¿Dónde vive, exactamente, la verdad financiera?

Aurora existe para no llegar ahí.

Un admin builder —Filament, Nova, Backpack— genera pantallas CRUD sobre tus modelos de Eloquent: resuelve la interfaz, no la lógica de un sistema financiero. Django ofrece un framework web y un admin genérico. Y Odoo es un ERP extensible; Aurora es algo distinto: una plataforma para construir ERPs. Es la capa de abajo —un kernel financiero, una fábrica de módulos y una frontera verificada— sobre la que esas UIs, incluida Filament que Aurora consume, se montan.

Generar pantallas es rápido al principio. El costo aparece cuando el sistema crece: cada módulo nuevo se acopla a los anteriores, cambiar una firma rompe otros en silencio y la consistencia depende de que alguien recuerde la regla. Aurora cambia la pendiente. Un módulo nace de un manifiesto determinístico, depende de contratos congelados del Platform SDK —no de implementaciones— y un cambio que rompe la frontera falla ruidoso en CI antes del merge. La plataforma se diseñó para el año 2, no solo para la demo.

Ningún constructor de paneles te da integridad financiera por construcción. En Aurora el kernel es el GL: un libro mayor que funciona como event log inmutable. El dinero se opera con BCMath sobre columnas numeric(15,2), nunca con float. Las cuentas se resuelven por determinación —nombre canónico, no por código que diverge entre plantillas—. Todo módulo orbita el GL y ninguno escribe en journal_lines directo. En la práctica, significa que inventario, ventas, tesorería o nómina hablan el mismo lenguaje financiero y producen estados consistentes por diseño, no por reconciliación nocturna. Y esas invariantes no son convenciones: son fitness functions que corren en cada build. Reconstruir ese sustrato sobre un admin builder es, precisamente, el trabajo que Aurora ya hizo.

Las reglas que gobiernan Aurora —GL inmutable, dinero en BCMath, cuentas por determinación, frontera verificada en CI— ya operan procesos reales de control de finanzas, impuestos, tesorería y analítica. Está construido sobre más de una década desarrollando sistemas financieros y analítica empresarial para compañías de manufactura y retail en Latinoamérica, no sobre una pizarra.