Por qué la captura de facturas debería vivir dentro de Business Central (y no en un portal externo)

Hay un patrón que se repite en muchas implantaciones de software de captura de facturas en empresas medianas españolas: la herramienta vive fuera del ERP, en un portal web independiente al que el equipo de cuentas a pagar entra cada mañana, revisa, valida, y luego “manda” las facturas al ERP mediante una integración. La integración pasa por una API. La API a veces se rompe. Cuando se rompe, alguien teclea las facturas a mano para no parar el cierre. Y al cabo de 18 meses, la dirección financiera descubre que el sistema externo ha dejado de cumplir su promesa.

Este patrón no es accidental. Es el resultado natural de implantar una herramienta cuyo modelo arquitectural está pensado para vivir aparte del ERP y conectar con él por una integración externa. Hay otra forma de hacerlo que evita estos problemas estructuralmente: una extensión nativa AL que vive dentro del propio Business Central.

La diferencia entre las dos formas no es académica. Tiene consecuencias muy concretas sobre la fiabilidad de la operación, la latencia entre captura y contabilización, los costes de mantenimiento, y lo que pasa cuando Microsoft saca una versión nueva de Business Central cada 6 meses.

Qué significa “vivir dentro de Business Central”

Microsoft Dynamics 365 Business Central tiene un sistema de extensiones nativas escritas en AL, el lenguaje propio del ERP. Una extensión AL se desarrolla, se publica en AppSource (el marketplace oficial de Microsoft) y se instala directamente en el tenant del cliente como cualquier otra funcionalidad de Business Central.

Una vez instalada, la extensión:

• Usa las tablas y los maestros existentes de Business Central (proveedores, cuentas, dimensiones, perfiles de contabilización).
• Usa los flujos nativos del ERP (workflows de aprobación, conciliación bancaria, libros y diarios).
• Hereda los permisos del sistema de roles de Business Central.
• Se actualiza automáticamente desde AppSource cuando Microsoft saca una versión nueva del ERP.
• No expone datos a fuera: todo el procesamiento ocurre dentro del entorno cloud del cliente.

Una solución externa, por contraste, es un sistema independiente que captura las facturas en su propio backend, las muestra en su propio portal, y las “envía” a Business Central mediante una API REST. Esa API es un puente que el cliente tiene que mantener vivo.

Cinco diferencias prácticas

A nivel técnico-operativo, las dos arquitecturas se separan en cinco puntos:

1. Fiabilidad bajo actualizaciones de Business Central. Microsoft saca una versión mayor de Business Central cada 6 meses (Wave 1 en abril, Wave 2 en octubre). Cada versión introduce cambios en APIs, en endpoints, en estructuras de datos. Una extensión AL nativa se actualiza junto con el ERP automáticamente desde AppSource: Microsoft garantiza que las extensiones certificadas siguen funcionando. Una integración por API externa necesita que el proveedor del software externo actualice su conector antes de que el cliente actualice su BC. Si no llega a tiempo, el cliente se queda atascado con una versión antigua del ERP o con una integración rota.

2. Latencia entre captura y contabilización. En una extensión nativa, la factura se captura, se procesa con OCR + IA, se vincula con su albarán y se contabiliza en el mismo segundo, dentro del mismo motor de datos. En una solución externa, la factura se captura en el portal externo, se almacena allí, espera a que el job de sincronización se ejecute (típicamente cada 5-15 minutos o por lote nocturno), se manda por la API a BC, y entonces se contabiliza. Esa latencia rompe la conciliación bancaria en tiempo real porque cuando llega el extracto bancario los pagos pueden no estar todos contabilizados todavía.

3. Único maestro de proveedores. En una extensión nativa, el proveedor que aparece en la captura es el mismo registro que el proveedor en Compras, en Pagos, en cuenta de gastos. Hay un solo maestro. En una solución externa, el sistema externo tiene su propio maestro de proveedores que se sincroniza con el de BC. Cualquier divergencia (un alta nueva en uno, un cambio de cuenta bancaria en el otro) se convierte en una factura mal vinculada que alguien tiene que corregir manualmente.

4. Aprobaciones nativas. Business Central tiene un motor de workflows muy potente que permite aprobar facturas por importe, por proveedor, por centro de coste, por dimensión, por usuario. Una extensión AL nativa usa ese motor: cuando una factura entra al sistema, dispara el workflow correspondiente y los aprobadores la firman desde la app móvil de Business Central. Una solución externa suele tener su propio sistema de aprobaciones dentro del portal externo, lo cual obliga al equipo a entrar a un portal distinto para aprobar (más fricción, menos adopción) y a mantener dos sistemas de roles paralelos.

5. Auditabilidad y compliance. Cuando un auditor pide la trazabilidad de una factura concreta, en una extensión AL nativa toda la pista vive dentro de Business Central: quién la capturó, cuándo, qué OCR la procesó, quién la aprobó, en qué fecha se contabilizó, contra qué pedido se casó. En una solución externa, parte del rastro vive en BC y parte en el sistema externo, y la reconstrucción del histórico requiere consultar dos sistemas y reconciliarlos. Para auditorías ISAE 3402, SAFT-PT (Portugal), IRAP/SOX (filiales US) y similares, la diferencia es operativamente sustancial.

Lo que cuesta más caro de la solución externa

Hay un coste oculto en las soluciones externas que muy pocas direcciones financieras cuantifican antes de firmar: el coste anual de mantener viva la integración.

Cada actualización de Business Central (cada 6 meses) puede romper o degradar la integración. Cada cambio en el portal externo (cada 3-6 meses) puede tener efectos colaterales sobre el flujo de datos. Cada vez que el equipo de IT del cliente cambia algo en el entorno (un certificado, una política de seguridad, un cambio de tenant), la integración necesita revisión.

En la práctica, las empresas con soluciones externas acaban dedicando 30-60 horas anuales a mantener viva la integración: pruebas tras cada release, escalado de incidencias entre dos proveedores (el del software externo y el partner de BC), parches puntuales, bypass manuales cuando algo falla.

A coste medio interno + externo, eso son 2.000-5.000 €/año de coste recurrente “invisible” que no aparece en la propuesta original pero sale año tras año. Una extensión nativa no tiene ese coste porque la actualización es automática y la responsabilidad es de Microsoft + el editor de la extensión.

Qué hace que una extensión sea una buena extensión nativa

No todas las extensiones AL en AppSource son iguales. Hay tres criterios técnicos que distinguen una buena extensión de una integración disfrazada de extensión:

1. ¿La extensión está certificada por Microsoft (Co-sell ready / App Source Certified)? AppSource solo lista extensiones que han pasado la validación técnica de Microsoft. Las extensiones privadas (instaladas via .app por el partner) no tienen esa garantía.

2. ¿Usa los maestros existentes de BC o crea sus propias tablas paralelas? Una buena extensión añade tablas para funcionalidad nueva específica (por ejemplo, un log de capturas OCR) pero usa los maestros estándar (proveedores, cuentas, dimensiones, perfiles). Una extensión mal diseñada crea tablas paralelas que duplican información existente.

3. ¿Funciona también para empresas que aún no están en Business Central? Una extensión bien arquitectada debería tener la capacidad de operar también como sistema autónomo o conectada a otro ERP mediante integraciones controladas, para clientes que están en transición a BC. Esto no es contradictorio con ser una extensión nativa: es una capa de abstracción adicional que da a la solución una vida útil más larga.

La pregunta correcta antes de elegir

Cuando una empresa con Business Central evalúa una herramienta de captura de facturas, la pregunta no es solo “¿cuál tiene mejor OCR?” o “¿cuál es más barata?”. Es:

“¿Esta solución va a estar funcionando exactamente igual de bien dentro de 3 años, después de 6 actualizaciones de Business Central, 5 cambios de versión del portal externo y un par de migraciones de tenant?”

Si la respuesta razonable es “sí, sin intervención”, estás ante una extensión AL nativa. Si la respuesta es “depende de que ambos proveedores mantengan la integración”, estás ante una dependencia externa que va a costar tiempo y dinero recurrente.

Para una organización que ya está en Business Central y planea quedarse, elegir externa cuando hay opción nativa es generar deuda técnica desde el día 1.

En resumen

• Las soluciones de captura externas viven en un portal aparte y se conectan con Business Central por una API. Esa API es un puente que hay que mantener vivo cada 6 meses (cada actualización de BC).
• Una extensión AL nativa vive dentro de Business Central, usa los maestros y workflows existentes, se actualiza automáticamente desde AppSource y no necesita mantenimiento de integración.
• 5 diferencias prácticas: fiabilidad bajo actualizaciones de BC, latencia entre captura y contabilización, maestro único de proveedores, aprobaciones nativas, auditabilidad consolidada.
• Las soluciones externas tienen un coste recurrente “invisible” de 2.000-5.000 €/año en mantenimiento de la integración que no aparece en la propuesta inicial.
• Una buena extensión nativa cumple 3 criterios: certificada por Microsoft (AppSource Certified), usa maestros estándar de BC y tiene capacidad de operar también como sistema autónomo o con otros ERPs.
• Para empresas que ya están en BC, elegir externa cuando hay opción nativa es generar deuda técnica desde el día 1.

---

¿Quieres una herramienta de captura de facturas que viva dentro de Business Central como extensión AL nativa? dvinvoice-hub está publicada en AppSource, usa los maestros existentes de BC, dispara los workflows nativos de aprobación y se actualiza automáticamente con cada versión del ERP. Funciona también de forma autónoma o con otros ERPs si todavía no estás en BC. Calcula tu bloque o pide una demo.