Integración del software de gestión de gastos con SAP, Sage y FacturasCloud

https://a.storyblok.com/f/146026/433x433/cfd74e99e1/spendesk-logo-square-1.png
Spendesk Team

Es el tercer día del cierre y tu equipo sigue tecleando tickets de tarjeta en SAP o cuadrando facturas en Sage. Otro mes más, la gestoría recibe un Excel que alguien tendrá que revisar línea por línea. El software de gestión de gastos ya tiene esos datos, pero no llegan automáticamente al sistema contable.

SAP, Sage y FacturasCloud no reciben la información de la misma manera. Por eso, preguntar si una herramienta «se integra» sirve de poco. Lo importante es saber qué datos se transfieren, en qué formato, quién valida los asientos y qué ocurre cuando algo falla.

En este artículo analizamos las principales rutas de integración con SAP, Sage y FacturasCloud, desde el pago con tarjeta hasta la contabilización, incluyendo los justificantes, el IVA, los proveedores, los centros de coste y los pagos.

Puntos Clave

SAP, Sage y FacturasCloud no utilizan la misma ruta de integración.

  • La conexión puede realizarse mediante un conector, una API o un fichero.
  • SAP Business One puede utilizar Service Layer, DI API, middleware o importaciones.
  • SAP S/4HANA Cloud utiliza servicios específicos para registrar asientos y supervisar errores.
  • Sage 50 y Sage 200 suelen trabajar con formatos de importación diferentes.
  • FacturasCloud puede depender de exportaciones Excel, PDFs y del trabajo de la gestoría.
  • Los proveedores, las cuentas, el IVA y los centros de coste deben coincidir en los sistemas.
  • Una factura y un pago pueden requerir asientos y diarios diferentes.
  • Los justificantes y los identificadores de factura deben conservarse durante todo el proceso.
  • Una prueba con un mes real de datos permite detectar errores antes del primer cierre.

¿Cómo se integra un software de gestión de gastos con SAP, Sage o FacturasCloud?

La integración suele seguir una de estas tres rutas:

  • Conector nativo.

  • Interfaz de programación de aplicaciones, conocida como API.

  • Exportación mediante ficheros.

El conector nativo conecta directamente el software de gestión de gastos con el sistema contable. Según la solución y su configuración, puede sincronizar el plan de cuentas, los proveedores, los códigos de IVA, los centros de coste y otros datos maestros.

La API permite intercambiar información de forma estructurada. Ofrece más flexibilidad, pero normalmente requiere desarrollo propio, un integrador o una plataforma de integración como servicio.

La exportación mediante fichero genera un CSV, un Excel u otro formato que después se importa en el sistema contable. Es una ruta habitual en Sage y en los procesos gestionados por asesorías y gestorías. Requiere más intervención manual, pero puede funcionar incluso cuando no existe una API pública o un conector nativo.

En las tres rutas pueden viajar los mismos tipos de información:

  • Plan de cuentas.

  • Proveedores.

  • Códigos de IVA.

  • Centros de coste.

  • Dimensiones analíticas.

  • Asientos.

  • Facturas.

  • Pagos.

  • Justificantes.

La diferencia está en quién mantiene esos datos y cómo se corrigen los errores. Con un conector o una API, parte de la información puede sincronizarse automáticamente. Con un fichero, el equipo debe comprobar que los datos maestros coinciden en los dos sistemas.

Antes de elegir una ruta, responde a estas tres preguntas:

  1. ¿Qué versión del sistema contable utilizas?

  2. ¿Cuántos gastos y facturas procesas cada mes?

  3. ¿Quién mantendrá la conexión cuando cambien el ERP, el plan contable o las reglas fiscales?

Del pago con tarjeta al asiento contable

Un gasto puede pasar por varias fases antes de llegar al libro diario:

  1. El pago con tarjeta, la factura de proveedor o la nota de gasto se registra con su justificante.

  2. El responsable correspondiente aprueba la operación.

  3. Contabilidad asigna la cuenta de gasto, el IVA soportado y el centro de coste.

  4. El equipo financiero comprueba que la línea está completa.

  5. El asiento se envía al sistema contable mediante un conector, una API o un fichero.

  6. El ERP o la gestoría valida la importación y devuelve los errores que deban corregirse.

Conviene que solo los gastos aprobados y preparados generen asientos. De esta manera, el equipo financiero revisa la información antes de exportarla y no tiene que perseguir justificantes o completar datos durante el cierre.

Imagina que una comercial paga con la tarjeta de empresa una noche de hotel de 180 euros, con un IVA del 10 % incluido. El desglose sería:

  • Base imponible: 163,64 euros.

  • IVA soportado: 16,36 euros.

  • Total: 180 euros.

El asiento podría ser:

Cuenta

Debe

Haber

629 Otros servicios

163,64 €

472 Hacienda Pública, IVA soportado

16,36 €

572 Bancos o cuenta de tarjeta

180,00 €

El tratamiento exacto depende del plan contable, del tipo de operación y de las reglas de la empresa.

Las facturas de proveedores siguen otro recorrido. Primero pueden generar una deuda en la cuenta del proveedor y, después, el pago cancela esa deuda contra el banco o la cuenta de la tarjeta.

Por eso, no basta con preguntar si la herramienta exporta gastos. También hay que confirmar si exporta:

  • Facturas pendientes.

  • Pagos.

  • Liquidaciones de tarjeta.

  • Comisiones bancarias.

  • Reembolsos.

  • Justificantes asociados.

Spendesk agrupa los pagos y las facturas en la pestaña de preparación, donde el equipo revisa el IVA, la cuenta de gasto y el proveedor. Después, la exportación puede generar el diario de compras, el diario de banco y los justificantes.

¿Te gusta lo que lees?

Publicamos nuevos artículos como este cada semana. Suscríbete a nuestro Newsletter para mantenerte informado.

SAP recibe los gastos por API, middleware o lotes

SAP no es un único sistema. La ruta de integración depende de si la empresa utiliza SAP Business One, SAP S/4HANA Cloud u otra solución del ecosistema SAP.

Antes de conectar un software de gestión de gastos con SAP, conviene confirmar:

  • Producto y versión.

  • Entorno cloud o local.

  • Entidades y sociedades que se conectarán.

  • Planes contables.

  • Tipos de documento.

  • Reglas de IVA.

  • Centros de coste.

  • Gestión de proveedores.

  • Tratamiento de pagos y partidas abiertas.

SAP Business One

En SAP Business One, la integración puede utilizar Service Layer, DI API, middleware o ficheros de importación.

Según la referencia de la API de Service Layer de SAP, Service Layer utiliza el protocolo OData y permite trabajar con diferentes objetos empresariales de SAP Business One.

La DI API, o Data Interface API, es otra opción para conectar aplicaciones externas con SAP Business One. La elección entre Service Layer y DI API depende de la versión, la arquitectura, el tipo de operación y las recomendaciones del partner de SAP. Las guías de integradores pueden ayudar a entender las diferencias, pero la decisión debe validarse para cada instalación.

Según la documentación de SAP, desde la versión 9.3 también es posible importar determinados asientos desde Excel. Esta opción puede ser útil cuando la empresa no necesita una conexión permanente y prefiere importar lotes preparados.

Antes de elegir una ruta, pregunta:

  • ¿Se sincronizan las cuentas y los proveedores?

  • ¿Se crean asientos completos o solo líneas contables?

  • ¿Cómo se validan los códigos de IVA?

  • ¿Qué ocurre si una subcuenta no existe?

  • ¿Cómo se evita duplicar un lote reexportado?

  • ¿Se guardan los justificantes en SAP?

  • ¿Se exportan también pagos y liquidaciones de tarjeta?

SAP S/4HANA Cloud

En SAP S/4HANA Cloud, los asientos externos pueden enviarse mediante los servicios de Journal Entry Post. La documentación de SAP contempla servicios síncronos y asíncronos para registrar asientos, según el volumen y el tipo de operación.

El servicio síncrono devuelve el resultado de la operación de forma inmediata. El servicio asíncrono puede ser más adecuado para determinados envíos masivos, aunque su configuración y supervisión requieren una definición previa del proceso.

La integración puede incluir:

  • Acuerdo de comunicación.

  • Escenario de comunicación.

  • Sociedad.

  • Cuenta contable.

  • Proveedor.

  • Impuestos.

  • Moneda.

  • Centro de coste.

  • Referencia de documento.

  • Fecha de contabilización.

Los errores se pueden supervisar mediante el Application Interface Framework, conocido como AIF. El equipo debe definir quién revisará el AIF, con qué frecuencia y qué procedimiento se utilizará para corregir y volver a enviar los datos.

La contabilización de un asiento y la compensación de partidas abiertas no son necesariamente la misma operación. Para compensar partidas de cuentas de mayor, proveedores o clientes, SAP documenta servicios específicos, como Journal Entry Clearing.

Por eso, confirma con el equipo responsable de SAP si el proceso cubre también:

  • Compensación de proveedores.

  • Pagos.

  • Liquidaciones de tarjeta.

  • Comisiones bancarias.

  • Partidas abiertas.

  • Conciliación bancaria.

Una integración con SAP debe probarse con datos reales

Antes de poner la conexión en producción, exporta un mes real de gastos a un entorno de prueba o a una copia controlada del ERP.

Incluye operaciones diferentes:

  • Gasto nacional con IVA.

  • Gasto extranjero.

  • Factura de proveedor.

  • Proveedor nuevo.

  • Cuenta inexistente.

  • Gasto con varias líneas.

  • Operación en moneda extranjera.

  • Gasto sin justificante.

  • Pago o liquidación de tarjeta.

La prueba debe confirmar que el asiento se crea correctamente, que los justificantes se pueden consultar y que los errores se pueden corregir sin duplicar operaciones.

Sage 50 y Sage 200 trabajan principalmente con ficheros de importación

En Sage, la ruta de integración suele depender del producto utilizado, de la versión instalada y del procedimiento de la gestoría.

Las soluciones más habituales utilizan un fichero de asientos que el equipo contable importa y valida. El formato puede ser diferente en Sage 50 y Sage 200, por lo que no conviene reutilizar una plantilla sin comprobarla.

Sage 50

Según la ayuda oficial de Sage 50, el complemento de importación y exportación de asientos puede admitir ficheros CSV, DBF o TXT con una estructura compatible con ContaPlus.

Dependiendo de la configuración, el fichero puede incluir:

  • Asientos.

  • Subcuentas.

  • Comentarios.

  • Fechas.

  • Importes.

  • Divisas.

Antes de importarlo, comprueba que:

  • Las cuentas existan.

  • Las subcuentas estén creadas.

  • Los códigos de IVA coincidan.

  • Los códigos ISO de divisa sean compatibles.

  • El formato de fecha sea correcto.

  • El asiento esté cuadrado.

  • El identificador no se haya importado anteriormente.

Un proveedor nuevo sin subcuenta puede bloquear la importación o generar un error que obligue a revisar el lote completo.

Sage 200

En Sage 200, la importación puede utilizar una plantilla de Excel con una fila por apunte. En una factura recibida, los datos del proveedor, el gasto y el IVA pueden aparecer en diferentes líneas del asiento.

La plantilla puede incluir:

  • Cuenta del proveedor.

  • Cuenta de gasto.

  • Base imponible.

  • Código de IVA.

  • Importe del impuesto.

  • Total de factura.

  • Fecha.

  • Número de factura.

  • Centro de coste.

  • Descripción.

La estructura exacta depende de la versión y de la configuración de Sage 200. Antes de crear la exportación definitiva, pide a la gestoría una plantilla de ejemplo y valida cada columna.

La gestoría debe formar parte del diseño

Una gestoría que trabaja con Sage recibe cada mes los ficheros de gastos de uno o varios clientes. Para que el proceso sea sostenible, debe quedar claro:

  • Quién crea los proveedores.

  • Quién asigna las cuentas.

  • Quién valida el IVA.

  • Quién importa el fichero.

  • Quién revisa los errores.

  • Quién autoriza una reexportación.

  • Cómo se relacionan los asientos con los justificantes.

Imagina que en octubre llega una factura de un proveedor nuevo sin subcuenta en Sage. Si el dato se descubre durante el cierre, la importación puede detenerse justo cuando menos tiempo queda.

Una alternativa es acordar que los proveedores nuevos se creen antes de exportar el lote y que el software de gestión de gastos utilice el mismo identificador que Sage. De esta forma, la gestoría recibe un fichero más limpio y reduce la revisión manual.

En las ediciones españolas de Sage, la exportación mediante fichero sigue siendo una ruta habitual.

FacturasCloud pasa por Excel y por la gestoría

FacturasCloud es un programa de facturación online dirigido a autónomos, pymes y asesorías. En este caso, la ruta de integración puede depender más de las exportaciones y del trabajo de la gestoría que de un conector contable nativo.

No hemos encontrado documentación pública suficiente para confirmar una API contable con el mismo alcance que otros sistemas. Antes de diseñar una conexión, conviene confirmar con FacturasCloud:

  • Si existe una API disponible.

  • Qué datos permite consultar.

  • Qué datos permite crear o modificar.

  • Si exporta facturas, gastos y pagos.

  • Si los justificantes se pueden descargar en bloque.

  • Si existe un entorno de pruebas.

  • Qué funcionalidades incluye cada plan.

  • Qué límites de uso se aplican.

Exportación de clientes, proveedores y gastos

Según la información disponible en su web, las plantillas oficiales de Excel permiten importar clientes, proveedores, productos y servicios.

La gestoría puede tener un perfil de solo lectura, descargar datos en Excel y PDF y obtener los adjuntos de gastos sin modificar documentos.

En este modelo, FacturasCloud puede actuar como fuente de información de facturación, mientras que la gestoría utiliza Sage, A3 u otro programa para generar los asientos contables.

Un ejemplo de proceso con FacturasCloud

Una agencia de 25 personas factura sus servicios en FacturasCloud y utiliza tarjetas corporativas para pagar sus gastos.

Cada mes:

  1. La agencia emite sus facturas en FacturasCloud.

  2. El equipo registra los gastos de tarjeta en el software de gestión de gastos.

  3. Los responsables aprueban las operaciones.

  4. Contabilidad asigna cuentas, IVA y centros de coste.

  5. La gestoría descarga las ventas y facturas de FacturasCloud.

  6. La empresa exporta los gastos con sus justificantes.

  7. La gestoría concilia proveedores, fechas e importes.

  8. El asiento final se genera en el programa contable.

El proceso será más sencillo si los dos sistemas utilizan códigos comunes para:

  • Proveedores.

  • Clientes.

  • Números de factura.

  • Cuentas de gasto.

  • Centros de coste.

  • Entidades.

  • Tipos de IVA.

Si la gestoría lleva la contabilidad en Sage o A3, puede utilizar los datos exportados para preparar el asiento sin volver a introducir cada gasto manualmente.

FacturasCloud y VERI*FACTU

VERI*FACTU regula el sistema informático utilizado para expedir facturas. Por tanto, hay que diferenciar entre:

  • Una herramienta de facturación que emite facturas.

  • Una herramienta de gestión de gastos que recibe justificantes y prepara información contable.

Según FacturasCloud, VERI*FACTU está incluido en sus planes. La empresa debe comprobar con su asesoría fiscal cómo se aplican las obligaciones a su situación concreta.

El Real Decreto 1007/2023 regula los requisitos de los sistemas informáticos de facturación. Los plazos y las modificaciones normativas deben verificarse antes de publicar el artículo o iniciar un proyecto.

La factura electrónica B2B es una obligación diferente. El Real Decreto 238/2026 desarrolla la Ley Crea y Crece, mientras que la Orden HAC/1028/2026 establece aspectos adicionales del sistema.

En cualquier caso, una integración debería conservar el número de factura, el proveedor, el justificante, el asiento y el pago. Esa trazabilidad será importante para responder a consultas de la gestoría y revisar el estado de cada factura.

Comparativa de rutas por sistema

Cada sistema tiene una ruta habitual. Esa ruta también determina quién configura la integración, quién importa los datos y quién corrige los errores.

Sistema

Ruta habitual

Qué se puede contabilizar

Quién lo configura

Riesgo de mantenimiento

SAP Business One

Service Layer, DI API, middleware o Excel

Asientos, proveedores, impuestos y cuentas de mayor

Partner de SAP o equipo de sistemas

Medio, por versiones, permisos y validaciones

SAP S/4HANA Cloud

Journal Entry Post, middleware o servicios de integración

Apuntes de mayor, proveedores, clientes, impuestos y retenciones

Sistemas, partner SAP o integrador

Medio-alto, por errores en AIF y compensación de partidas

Sage 50

CSV, DBF o TXT

Asientos, subcuentas y comentarios

Contabilidad o gestoría

Bajo si las cuentas y subcuentas coinciden

Sage 200

Plantilla Excel u otro formato compatible

Asientos, proveedores, facturas e IVA

Contabilidad o gestoría

Medio, por plantillas, cuentas y duplicados

FacturasCloud

Excel, PDF y exportación a la gestoría

Facturas, gastos, proveedores y justificantes

Empresa y gestoría

Medio, por la gestión de datos en dos sistemas

Criterios para evaluar conectores, APIs y exportaciones

Evalúa cualquier integración con estas comprobaciones:

  • Comprueba si descarga del sistema contable el plan de cuentas, los proveedores y los códigos de IVA.

  • Revisa el mapeo de cuentas, impuestos, diarios, centros de coste y dimensiones analíticas.

  • Pregunta con qué frecuencia sincroniza y si la sincronización es bidireccional.

  • Confirma si exporta pagos, liquidaciones de tarjeta y comisiones, además de facturas.

  • Verifica que el número de factura y el justificante viajen con el asiento.

  • Pide documentación actualizada de la API o de la plantilla de importación.

  • Pregunta cómo se registran los errores.

  • Confirma si se puede reexportar un lote sin duplicar asientos.

  • Averigua quién adapta la conexión cuando cambia la versión del sistema contable.

  • Calcula el coste de mantenimiento y la dependencia del integrador.

La sincronización bidireccional suele requerir un conector o una API. Con un fichero, los datos maestros se actualizan manualmente en ambos sistemas.

Antes de la puesta en marcha, exporta un mes real de gastos e impórtalo en una copia del ERP o en un entorno de pruebas. Aparecerán los problemas reales:

  • Una subcuenta inexistente.

  • Un código de IVA mal mapeado.

  • Un proveedor duplicado.

  • Una fecha interpretada incorrectamente.

  • Un asiento descuadrado.

  • Un justificante que no se puede abrir.

  • Un lote que no se puede reexportar sin crear duplicados.

Corregir esos problemas antes del primer cierre cuesta mucho menos que hacerlo cuando la gestoría ya está esperando el fichero.

Sin un conector nativo, la calidad de la exportación determina cuánto trabajo manual queda. Spendesk permite ajustar la plantilla de exportación a tu ERP, incluyendo columnas, códigos de diario, formato de fecha, decimales y campos analíticos.

Para desarrollos a medida con SAP u otros sistemas, Spendesk ofrece además una API disponible bajo solicitud.

Con la estructura adecuada, el equipo financiero puede dedicar el cierre a revisar y analizar el gasto, en lugar de transcribirlo.

¿Quieres saber cómo funciona Spendesk?

Prueba nuestro demo interactivo y descubre como controlar el gasto y las aprobaciones de principio a fin.

Probar demo interactivo