Contabilidad embebida: desarrollo interno frente a compra para marketplaces

Una lista de alcance, un modelo de coste con suposiciones explícitas y las condiciones bajo las cuales cada respuesta es la correcta.

Tarde o temprano, todo marketplace termina construyendo un libro mayor (ledger). La única duda es si se hace de forma deliberada, como un sistema provisto de controles, o por accidente, en forma de una columna balance a la que escriben tres servicios distintos y de la que nadie se fía del todo.

Este artículo trata sobre cómo tomar esa decisión a propósito. Analiza en qué consiste realmente el trabajo, cómo calcular su coste sin autoengaños y cuáles son las condiciones específicas en las que desarrollar internamente es la respuesta acertada, porque a veces lo es.

Qué significa "contabilidad embebida" en este contexto

La contabilidad embebida significa que los libros residen dentro de tu propio producto y no en una aplicación independiente que alguien abre aparte. Tu software registra los asientos a medida que ocurren los eventos, tus usuarios ven lo que muestra tu interfaz y nadie tiene que exportar hojas de cálculo para entregárselas a un contable al cierre del mes.

Para un marketplace, esto abarca como mínimo: los pagos recibidos de los compradores, los importes adeudados a los vendedores, las comisiones devengadas, las comisiones de procesamiento de pagos, el IVA de tus servicios y el de las entregas subyacentes, los reembolsos, las devoluciones de cargos (chargebacks), las reservas, los pagos a vendedores y la conciliación de todo ello con un banco o proveedor de pagos.

Qué estás construyendo en realidad si decides desarrollarlo

El libro mayor en sí es la parte pequeña. Los equipos suelen acotar solo el primer elemento y descubren el resto más adelante.

Componente	En qué consiste
Diario y cuentas	Asientos cuadrados, plan contable, tipos de cuenta, saldos iniciales
Inmutabilidad	Almacenamiento de solo adición (append-only), flujo de reversión y corrección, sin modificaciones directas (in-place)
Control de periodos	Cierre, bloqueo, rechazo de asientos tardíos, reapertura controlada con registro de auditoría
Idempotencia	Claves, almacenamiento de respuestas anteriores, detección de colisiones ante cargas útiles modificadas
Gestión monetaria	Aritmética exacta con decimales o unidades menores, códigos de divisa, tipos de cambio y su procedencia, cuentas de redondeo
Motor de IVA	Tipos impositivos por país con fechas de validez, lugar de realización del hecho imponible (place of supply), inversión del sujeto pasivo (reverse charge), normas de proveedor estimado (deemed supplier), exenciones
Comprobaciones de identificación de IVA	Validación frente al registro oficial, caché, marcas de tiempo, identificadores de solicitud, cola de revisión manual para errores
Documentos	Facturas, abonos, numeración correlativa sin huecos por serie y año, renderizado en PDF, envío
Facturación electrónica	Formatos estructurados como EN 16931 UBL y formatos nacionales de cada país cuando sean obligatorios
Ingesta bancaria	Importación de extractos o conexión bancaria con consentimiento, deduplicación de transacciones ya importadas
Conciliación	Reglas de coincidencia, puntuación, coincidencias parciales, excepciones que una persona pueda resolver
Pagos a vendedores	Generación de ficheros de pago, lotes de pago, vinculación de los pagos con las partidas subyacentes
Informes	Balance de comprobación, balance de situación, cuenta de pérdidas y ganancias, flujo de caja, resúmenes de IVA, antigüedad de saldos
Registros y declaraciones fiscales	Todo lo que exijan tus países, en el formato que la administración acepte
Auditoría	Actor, acción, entidad y la modificación en sí, consultable, para cada cambio
Retención y exportación	Retención de diez años para los registros del régimen OSS, exportación completa de datos, archivo defendible

Aproximadamente dos de esas diecisiete filas corresponden a lo que la mayoría de los equipos imagina cuando dicen "vamos a programar un libro mayor".

Calcular el coste de forma realista

Cualquier cifra aquí depende de tu equipo, así que toma lo siguiente como un método y no como un presupuesto cerrado. Toma los componentes anteriores, asígnale a cada uno un tamaño en semanas de ingeniería basándote en la velocidad de tu propio equipo y aplica después tres correcciones que las estimaciones suelen pasar por alto.

Primera corrección: los componentes de cumplimiento normativo no son de una sola vez. Los tipos impositivos cambian, los umbrales cambian, los formatos cambian y el paquete de medidas sobre el IVA en la era digital (VAT in the Digital Age, ViDA) de la Unión Europea trae obligaciones con fecha fija: cambios en el OSS y el IOSS a partir del 1 de enero de 2027, ampliación de las normas para plataformas desde el 1 de julio de 2028 y reporting digital transfronterizo a partir del 1 de julio de 2030. Desarrollarlo por tu cuenta significa que te encargas de cada una de estas migraciones.

Segunda corrección: el trabajo de corrección perdura más que el de desarrollo de funcionalidades. La primera versión cubre el camino feliz (happy path). La larga cola incluye reembolsos posteriores a los pagos, reembolsos parciales, devoluciones de cargos que llegan semanas más tarde, redondeos de divisa, webhooks duplicados y ficheros de liquidación que no coinciden con tus registros. Aquí es donde el calendario se desvanece.

Tercera corrección: el contable es un miembro clave, no un revisor. Unos libros que un profesional financiero no quiera firmar no están terminados, y ese feedback suele llegar tarde en un desarrollo interno.

Una comprobación útil: calcula el coste del desarrollo viable más pequeño -libro mayor, correcciones, bloqueo de periodos, idempotencia, gestión monetaria, IVA de un país, facturas, importación bancaria, conciliación y un conjunto básico de informes- y compáralo con un año de servicio por uso. Los planes publicados de Nordlet comienzan en 10 euros al mes con 3.000 peticiones incluidas y llegan hasta los 300 euros al mes con 200.000 peticiones. Si un desarrollo cuesta una fracción de lo que cobra un ingeniero al año, hay un argumento de peso para construirlo. Si cuesta varios años de ingeniería más un mantenimiento permanente, la comparación deja de tener sentido, y la brecha se amplía cada año que cambian las normativas.

Cuándo desarrollar internamente es realmente la mejor opción

Tres casos, todos reales.

Tu libro mayor es tu producto. Si estás construyendo una plataforma de pagos, un producto bancario o un monedero (wallet) donde el comportamiento del saldo bajo concurrencia es tu elemento diferenciador, el libro mayor es fundamental y debe ser tuyo. Plantéate utilizar productos de infraestructura de libros mayores en lugar de empezar desde cero, y mantén la contabilidad legal separada.

Tu modelo no encaja en ningún sistema contable. Algunos marketplaces tienen estructuras de liquidación verdaderamente inusuales: repartos entre múltiples partes con liberaciones condicionales, depósitos en garantía (escrow) con hitos por fases, políticas complejas de reservas. Si ningún producto lo modela y los apaños son peores que programarlo, constrúyelo.

Tu volumen hace que el modelo por uso no sea el adecuado. Con un nivel de transacciones extremadamente alto, el precio por petición deja de ser atractivo. Modélalo con números reales antes de darlo por sentado, porque la palabra "extremadamente" aquí se refiere a un volumen superior al que alcanzan la mayoría de las plataformas.

Cuándo comprar es la opción correcta

Comprar gana cuando la contabilidad es necesaria pero no diferenciadora, que es lo habitual. Nadie elige tu marketplace porque los asientos de tu diario sean elegantes. Solo se dan cuenta cuando las cuentas fallan.

Comprar también es la decisión acertada cuando tus obligaciones abarcan varios países. Las normas de IVA por país, la conservación de justificantes y las obligaciones de facturación electrónica constituyen un flujo de mantenimiento permanente, y un proveedor amortiza ese trabajo entre todos sus clientes. Nordlet incluye el IVA de la UE por país con validación VIES, cálculo de declaraciones OSS e IOSS, registros i.SAF y EN 16931 UBL para Peppol como parte del producto y no como un proyecto que debas programar en tu calendario.

Una vía intermedia a la que llegan la mayoría de los equipos

La solución práctica suele ser ninguna de las dos anteriores. Es la siguiente: compra el libro mayor, desarrolla el flujo de trabajo.

El backend contable gestiona los asientos, el tratamiento fiscal, los documentos, el cierre de periodos y la pista de auditoría. Tu producto gestiona todo lo que ven tus usuarios y cada regla de negocio específica de tu marketplace: cuándo se liberan los fondos, en qué consiste la política de reservas, cómo se gestionan las disputas o qué muestra el panel del vendedor. Llamas a la API de contabilidad en los momentos en que se compromete dinero y te quedas con las partes que realmente son tuyas.

Esa frontera también resiste los cambios mucho mejor que las alternativas. Un nuevo país implica añadir configuración y no un proyecto. Una nueva política de pagos es tu código, no una solicitud a un proveedor.

Qué decidir antes de comprometerte

¿Tu libro mayor es un elemento diferenciador o una obligación? Sé sincero; la mayoría son obligaciones.
¿Cuántos países y qué exige cada uno? ¿Solo tipos impositivos, o declaraciones, o registros, o presentación telemática?
¿Cuál es tu estrategia de corrección? Los reembolsos posteriores a los pagos y las devoluciones de cargos tardías son los casos que dejan al descubierto un diseño frágil.
¿Quién firma los libros? Involucra a esa persona antes de cerrar el diseño, no después.
¿Cuál es el plan de retención a diez años? Los registros del OSS deben conservarse durante diez años desde el final del año de la transacción, y un archivo es un sistema, no una copia de seguridad.
¿Cómo sería una migración dentro de tres años? En ambas direcciones. Crea una exportación de prueba el primer día y mantén su funcionamiento.

FAQ

¿Cuánto se tarda en construir un libro mayor para un marketplace?

Una primera versión que publique asientos cuadrados puede estar funcionando en cuestión de semanas. Una versión que gestione reembolsos posteriores a los pagos, devoluciones de cargos tardías, redondeos multidivisa, webhooks duplicados de proveedores, cierre de periodos y una auditoría que un contable acepte requiere mucho más tiempo, y el mantenimiento no termina nunca. Estima la segunda opción, porque eso es lo que significa estar en producción.

¿Podemos empezar con una columna `balance` y migrar más tarde?

Puedes hacerlo, y muchos lo hacen, pero planifica la migración sabiendo que será más difícil que el desarrollo original. Reconstruir el historial a partir de un saldo modificable solo es posible si has conservado cada evento que lo alteró, lo que equivale a decir que, en realidad, ya tenías un libro mayor.

¿Una API de contabilidad embebida sustituye a nuestro equipo financiero?

No. Elimina el registro manual y la conciliación. Alguien sigue teniendo que cerrar el mes, revisar las excepciones, tomar decisiones de criterio y presentar las declaraciones.

¿Qué pasa con el RGPD si el libro mayor es inmutable?

Conserva los datos monetarios y las referencias seudónimas en los registros inmutables, y los datos personales en un sistema separado con sus propios procesos de retención y supresión. La inmutabilidad se aplica al evento financiero, no a cada atributo asociado a él.

¿Es el software de contabilidad de código abierto (open source) una opción intermedia?

Es una opción real, pero cambia el coste en lugar de eliminarlo: asumes por tu cuenta el alojamiento, las actualizaciones, la localización por países y las modificaciones normativas. Valora económicamente todo ello antes de considerar que el ahorro en licencias es el panorama completo.