Billing crea el cobro; recognition mide revenue ganado
Invoice y revenue pueden ocurrir en momentos distintos. Suscripciones prepagadas, implementation fees, usage, credits y contract modifications muestran que cash, invoice y earned revenue no son equivalentes.
Un invoice puede relacionarse con varias performance obligations y una obligación puede reconocerse durante varios periodos.
Dominios separados crean controles más claros
Billing necesita pricing, metering, proration, tax y collection state. Recognition necesita contract allocation, performance obligations, schedules y accounting evidence. Compartir source data es útil; compartir todos los estados y reglas crea coupling innecesario.
La frontera debe ser explícita
Define qué commercial events alimentan recognition, cómo se versionan amendments y cómo cada amount reconocido puede trazarse a contract, invoice, usage y adjustments.
La arquitectura no sustituye el criterio contable
El tratamiento exacto depende del estándar, contrato y professional judgment. La infraestructura debe preservar evidencia y controles, no hard-codear invoice date = revenue date.
Mantén trazables eventos comerciales y contables
Separación no significa sistemas desconectados. Billing debe emitir eventos comerciales durables—invoice issued, usage rated, credit applied, contract changed, payment collected—con identificadores que permitan a recognition relacionar accounting treatment con evidencia comercial. Recognition puede mantener schedules y adjustments propios sin pedir que billing se comporte como general ledger.
La traceability importa especialmente cuando cambian contratos. Upgrades, downgrades, cancellations, credits y amendments pueden modificar invoices futuras y tratamiento contable. Si ambos dominios comparten solo un snapshot actual, finance pierde la historia necesaria para explicar cambios en recognized amount. Eventos versionados preservan la secuencia.
No acoples pricing releases con financial close
Billing cambia con frecuencia porque producto lanza planes, descuentos, packaging y usage models. Revenue recognition opera con otra disciplina porque afecta reporting financiero y audit. Un motor único fuerza ambos release cadences: cambios comerciales se vuelven cambios de riesgo contable y controles de accounting pueden frenar iteración ordinaria de producto.
Un boundary limpio permite que cada dominio evolucione bajo governance apropiado compartiendo evidencia validada. Producto puede ampliar pricing sin reescribir recognition schedules y finance puede ajustar política contable sin cambiar cómo se factura al cliente.
Diseña reconciliación entre los dominios
Al separar billing y recognition, la arquitectura necesita reconciliation explícita. Finance debe explicar la relación entre contracted consideration, billed amounts, cash collected, deferred balances y recognized revenue. Las diferencias no necesariamente son errores, pero deben ser esperables y explicables.
La reconciliación puede organizarse por contrato, invoice line, service period o performance obligation según el negocio. El principio es que el boundary produzca evidencia, no black boxes. La separación debe mejorar controlabilidad y no desplazar incertidumbre.
Usa estándares contables como requirements, no como code templates
Estándares como IFRS 15 proporcionan principios sobre revenue from contracts with customers, pero la implementación depende de contract facts y juicio contable. La arquitectura debe ofrecer schedules configurables, allocation inputs, modifications y audit evidence en vez de suponer que una fórmula universal puede deducir tratamiento desde una invoice.
Ese enfoque también evita convertir producto en asesoría contable accidental. La infraestructura debe permitir que el juicio profesional sea operacionalmente implementable y auditable; no sustituirlo.
Billing y recognition responden preguntas distintas.
Cash, invoice y revenue timing pueden divergir.
Separar dominios reduce coupling.
Preserva traceability a contract y evidencia operativa.