Conectar PrestaShop con tu software contable: Xero, QuickBooks y más

Última revisión: junio de 2026. Reglas OSS vigentes desde el régimen de la UE posterior a 2021; rutas del back office verificadas en PrestaShop 1.7, 8.x y 9.x. Confirma siempre el tratamiento fiscal con tu propio asesor contable.

Esta es la diferencia que decide lo doloroso que será tu cierre de mes: PrestaShop es el sistema que cobra el dinero, y tu software contable es el sistema que tiene que explicar ese dinero ante la autoridad fiscal. No son el mismo trabajo. Tu tienda registra un pedido con un cliente, un transportista, un método de pago y un carrito de productos. Tu contable necesita una factura con numeración secuencial, una cuenta de ingresos, un código fiscal y una factura rectificativa por cada reembolso, en un formato que cuadre hasta el último céntimo. Conectar ambos sistemas consiste en traducir un modelo al otro. Si esa traducción está bien hecha, los libros prácticamente se cierran solos; si está mal, acabarás conciliando el IVA a mano a las 11 de la noche del último día del trimestre.

Esta guía trata específicamente de conectar PrestaShop con software contable, Xero, QuickBooks y los demás, para que los pedidos se conviertan en facturas correctas y auditables sin volver a teclear datos. No va de conectar PrestaShop con un ERP completo para stock y compras (ese es otro problema, con otra forma; consulta conectar PrestaShop con tu ERP y, para la pregunta de "cuándo lo necesito", cuando tu tienda deja atrás el trabajo manual). Aquí, el alcance es el libro contable: facturas, impuestos, reembolsos, comisiones y los números que tu contable valida.

Qué tiene que fluir realmente desde PrestaShop hacia la contabilidad

Antes de elegir una herramienta, deja claro qué datos debe transportar la conexión. PrestaShop ya genera la mayor parte; el trabajo de la integración es mapear cada pieza al lugar correcto de tu plan contable, no recrearla. Los objetos importantes viven en tablas bien definidas de PrestaShop, y conocer sus nombres te dice exactamente qué está leyendo una integración:

• La factura, no el pedido. Un pedido de PrestaShop (ps_orders) todavía no es un documento contable. La factura es un objeto separado (OrderInvoice / ps_order_invoice) que se genera cuando el pedido alcanza un estado facturable, y lleva su propio número. A tu contabilidad le importa la factura. Sincroniza pedidos sin factura y crearás ingresos que aún no existen legalmente.
• Impuestos desglosados por tipo. PrestaShop almacena el impuesto por línea y por factura (ps_order_detail_tax, ps_order_invoice_tax). Un solo pedido puede llevar dos o tres tipos de IVA distintos: productos al tipo general, productos al tipo reducido, envío al 0 %. La integración debe conservar ese desglose, no solo un total único.
• Reembolsos y cancelaciones como facturas rectificativas. Un reembolso en PrestaShop es un abono (OrderSlip / ps_order_slip), con su propia numeración secuencial. En tu software contable debe entrar como una factura rectificativa contra la factura original, no como una venta negativa, y nunca como una eliminación silenciosa.
• Pago frente a factura. Lo que pagó el cliente (ps_order_payment) y lo que facturaste son dos eventos distintos. Marcar una factura como "pagada" en la contabilidad debe depender del registro de pago, para que caja e ingresos concilien por separado.
• Comisiones de pasarela y envío. Stripe y PayPal se quedan una comisión antes de que el dinero llegue; los ingresos por envío (lo que pagó el cliente) y el coste de envío (lo que pagaste al transportista) son dos líneas diferentes. Nada de esto se ve en una sincronización ingenua de "total del pedido → ingresos".

¿Y qué implica esto? Si puedes nombrar estos cinco flujos, puedes evaluar cualquier conector en cinco minutos: solo tienes que preguntar cuáles gestiona y cuáles deja discretamente fuera.

La decisión antes de la herramienta: quién controla el número de factura

Esta es la única elección que condiciona toda integración contable, y la mayoría de guías la pasan por alto. En casi todas las jurisdicciones, las facturas de venta y las facturas rectificativas deben ser secuenciales y únicas; en algunas, además, la secuencia debe ser sin saltos, o cualquier salto debe poder explicarse y auditarse. La pregunta es qué sistema será la fuente de verdad para esa secuencia.

Si PrestaShop controla la numeración, la secuencia nativa es configurable pero poco fina; y un salto sin explicación (una factura cancelada o ausente, un cambio manual en la base de datos, una migración fallida o un reinicio de secuencia mal configurado) es exactamente el tipo de cosa que un auditor señalará. Dos de nuestros módulos existen precisamente para ese punto de control: Invoice Number y Order Number te permiten definir el prefijo, el valor inicial y el formato para que los documentos de PrestaShop sigan la secuencia anual, sin saltos, que espera tu contable, en lugar de pelearte con los valores por defecto del núcleo. El beneficio es específico, pero real: el documento que descarga tu cliente y el documento que archiva tu contable llevan el mismo número legalmente válido, así que la conciliación es una búsqueda, no una investigación.

Xero

Xero es una opción habitual para tiendas del Reino Unido y Europa, y se lo ha ganado: una API bien documentada, multimoneda nativa y una gestión del IVA que aguanta bien las ventas transfronterizas. Para PrestaShop, la conexión casi siempre es indirecta: un servicio de middleware o un módulo dedicado lee los pedidos facturados y crea las facturas correspondientes en Xero, porque Xero no tiene un plugin nativo propio para PrestaShop.

Las cuatro cosas que realmente determinan si una conexión con Xero es correcta:

• Mapeo del plan contable. Tus categorías (o productos) de PrestaShop deben mapearse a cuentas de ingresos en Xero. Una tienda que vende productos físicos y descargas digitales normalmente querrá separarlos en cuentas distintas; decide el mapeo antes de la primera sincronización, porque remapear después de miles de facturas es desagradable.
• Mapeo de tipos impositivos. Una regla de impuestos de PrestaShop (Back Office → Internacional → Impuestos → Reglas de impuestos) no es el mismo objeto que un tipo impositivo de Xero. Debes mapear cada una explícitamente: "FR Standard 20%" de PrestaShop al tipo equivalente de Xero, y lo mismo para cada país al que vendas. Si omites una, las ventas de ese país se contabilizarán con el impuesto incorrecto, o sin impuesto.
• Estado del pago. Una factura solo debe marcarse como pagada en Xero cuando PrestaShop confirma el pago. Haz que dependa del estado pagado del pedido, no de la creación de la factura, o tu posición de caja aparecerá inflada.
• Multimoneda. Si vendes en GBP, EUR y USD, deja que Xero controle los tipos de cambio y contabilice las facturas en la moneda de venta. No conviertas antes en la integración: perderás la pista de auditoría del importe en la moneda original.

El error más común con Xero es sincronizar demasiado. Empieza solo con pedidos facturados y pagados. Los pedidos en borrador, los carritos abandonados y los pagos pendientes no tienen lugar en tu contabilidad hasta que el dinero haya cambiado de manos.

QuickBooks Online

QuickBooks Online es habitual entre comerciantes de Estados Unidos y también puede servir en algunas configuraciones europeas, con un ecosistema de conectores maduro: la mayoría de plataformas de middleware lo soportan de serie. Que encaje de verdad en una tienda europea depende de tus requisitos locales de impuestos y facturación electrónica, así que compruébalos antes de comprometerte. El matiz para vendedores transfronterizos es que QuickBooks modela el impuesto sobre las ventas (EE. UU., basado en destino, por estado/condado) de forma muy distinta al IVA (UE). Si vendes en ambos mercados, la integración debe crear el apunte fiscal correcto según la ubicación del cliente: un pedido de EE. UU. lleva una línea de impuesto sobre las ventas, un pedido de la UE lleva una línea de IVA; y esa lógica vive en el conector, no en QuickBooks.

Configuración práctica que compensa:

• Usa clases o ubicaciones. Si gestionas más de una tienda PrestaShop (por ejemplo, una tienda separada por país), las clases de QuickBooks te permiten mantener separables los ingresos de cada tienda en el P&L sin abrir un segundo archivo de QuickBooks.
• Agrupa, no emitas en flujo continuo. La sincronización en tiempo real suena atractiva; un lote diario u horario es más fiable y mucho más fácil de depurar cuando falla una factura. Quieres encontrar un problema en un lote de 40, no perseguirlo dentro de un flujo en vivo.
• Decide la granularidad de producto. ¿Cada producto de PrestaShop se convierte en un artículo de QuickBooks, o agregas los ingresos por categoría? Por producto te da informes a nivel de producto y una lista de artículos mucho más grande que mantener; por categoría mantiene QuickBooks ligero. La mayoría de tiendas viven mejor agregando.
• Refleja los abonos como notas de crédito. Un abono de PrestaShop debe crear una nota de crédito de QuickBooks contra la factura original: mismo importe, mismo tratamiento fiscal.

Las otras plataformas, y por qué decide tu país

Xero y QuickBooks dominan la conversación en inglés, pero la herramienta correcta suele ser la que esperan tu contable local y tu autoridad fiscal. El enfoque de integración cambia en consecuencia:

• Sage, muy consolidado en el Reino Unido y Francia, habitual en empresas más grandes; el enfoque de integración depende del producto Sage, con opciones que van desde conectores API (Sage Business Cloud, Intacct) hasta middleware y exportaciones programadas.
• Datev, el estándar de facto en Alemania, porque la mayoría de asesores fiscales alemanes (Steuerberater) trabajan con él. Rara vez quieren una API; quieren una exportación compatible con Datev que puedan importar. Para estos contables, una canalización limpia de CSV/exportación supera a cualquier conector en tiempo real.
• Fakturownia / inFakt / wFirma, plataformas polacas de facturación e impuestos. Las reglas polacas de numeración y declaración JPK son estrictas, lo que hace que la decisión anterior sobre "quién controla el número de factura" tenga un peso especial aquí.
• Fattura24 / Aruba, Italia exige facturación electrónica (fatturazione elettronica) a través del sistema de intercambio SDI. Estas plataformas gestionan el envío a SDI; el trabajo de tu integración de PrestaShop es alimentarlas con una factura correctamente estructurada, no hablar directamente con SDI.
• Herramientas tipo FreshBooks / Debitoor, facturación más sencilla para microempresas y autónomos, normalmente alimentada por exportación en lugar de una integración profunda.

Para cualquier plataforma sin conector listo para usar, la integración casi siempre se reduce a una exportación estructurada que el software contable (o tu contable) importa según un calendario. Eso no es un paso atrás: para un flujo Datev o Fattura24 es exactamente lo que quiere el sistema receptor.

Qué contiene realmente un archivo de exportación contable

Si tu camino es la exportación (Datev, JPK, "mándame simplemente un CSV"), conviene saber qué columnas espera el receptor, porque una cabecera limpia es media batalla. La importación del contable no quiere la vista de pedido de tu escaparate; quiere filas a nivel de factura con el impuesto desglosado por tipo. Una cabecera CSV funcional para exportar facturas de venta se ve así:

invoice_number,invoice_date,order_reference,customer_name,customer_vat_number,country,currency,net_amount,tax_rate,tax_amount,gross_amount,payment_method,document_type
INV-2026-000412,2026-06-18,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,200.00,0.00,0.00,200.00,bankwire,invoice
INV-2026-000412,2026-06-18,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,50.00,19.00,9.50,59.50,bankwire,invoice
CN-2026-000031,2026-06-20,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,-50.00,19.00,-9.50,-59.50,bankwire,credit_note

Dos cosas que conviene observar: cada tipo impositivo obtiene su propia fila (así que una factura con varios tipos ocupa varias líneas que suman el total del documento), y un reembolso aparece como un credit_note con importes negativos contra el order_reference original, nunca como una fila de factura eliminada o editada. Confirma los nombres exactos de las columnas y el formato de fecha con tu contable antes de la primera ejecución; Datev y JPK tienen cada uno su propio diseño obligatorio, pero la forma, una fila por tipo, facturas rectificativas en negativo, es constante.

Dos caminos hacia la contabilidad: módulo nativo frente a middleware

Una vez sabes qué debe fluir y quién controla la numeración, hay dos formas realistas de mover los datos. No son mutuamente excluyentes, muchas tiendas usan un módulo para facturas y un conector middleware para una plataforma concreta, , pero ayuda ver claramente el equilibrio.

En el lado de los módulos, nuestro módulo Financial Revolution gestiona la generación, numeración y exportación de facturas en formatos que tu plataforma contable puede consumir. Cuando el entregable es un archivo limpio según calendario, el caso de Datev o JPK, , Invoice CSV List Exporter extrae los datos de factura e impuestos por tipo que importa tu contable, mientras que Orders CSV List Exporter cubre el lado bruto de los pedidos cuando eso es lo que necesita el sistema receptor. La consecuencia práctica: puedes poner en marcha una fuente contable precisa desde el back office, sin factura recurrente de middleware y sin que los datos de pedidos salgan de tu servidor; algo que a menudo decide la elección en un flujo Datev o JPK donde el contable solo quiere un archivo limpio según calendario. (Y si ese calendario debe ejecutarse sin intervención, Cron Manager es lo que lanza y registra la exportación recurrente para que una ejecución fallida sea visible, no silenciosa.)

El middleware justifica su suscripción cuando quieres una sincronización en vivo y sin intervención con Xero o QuickBooks específicamente, y valoras los reintentos, registros y conectores premapeados incorporados. Si tu motivo para recurrir a Zapier o Make es una automatización más amplia de la tienda en lugar del libro contable en sí, ese es otro tema: la mecánica de construir esos flujos se trata en Zapier y Make para PrestaShop y el enfoque sin código en automatizar flujos de trabajo sin escribir código.

IVA transfronterizo: la parte que convierte una tarea contable en una legal

Si vendes a través de fronteras dentro de la UE, el IVA es donde una integración contable deja de ser una comodidad y pasa a ser cumplimiento normativo. PrestaShop captura los hechos brutos; tus libros tienen que declararlos correctamente.

• OSS (One-Stop Shop). Desde julio de 2021, una tienda de la UE puede declarar el IVA de todos los Estados miembros mediante una única declaración OSS, pero solo si tus registros saben qué tipo de qué país se aplicó a cada venta. PrestaShop ya almacena el destino y la regla fiscal aplicada por factura; la integración debe llevar esa dimensión de país hasta la contabilidad, o tu declaración OSS será una conjetura.
• Inversión del sujeto pasivo B2B. Si vendes a una empresa con un número de IVA intracomunitario válido, no cobras IVA: el comprador se autorrepercute el impuesto. Eso significa que tu integración debe contabilizar la venta como una operación con inversión del sujeto pasivo, no como una venta con IVA cero, que para la autoridad fiscal son cosas distintas. Validar el número en el momento del pedido es el requisito previo; nuestro Automatic EU VAT Checker verifica los números de IVA contra VIES en tiempo real para que el pedido quede etiquetado correctamente antes de llegar a tus libros.
• Exportaciones fuera de la UE. Las ventas fuera de la UE suelen estar exentas o al 0 %, pero aun así deben aparecer en la contabilidad como exportaciones: presentes, no invisibles.

La regla práctica: deja bien resuelto el IVA transfronterizo antes de escalar volumen. Un mapeo fiscal incorrecto es una pequeña molestia con 30 pedidos al mes y una corrección de cinco cifras con 3.000.

Errores que afectan a toda integración contable

Independientemente de la herramienta que elijas, se repite el mismo puñado de fallos. Diseñar pensando en ellos desde el principio es más barato que descubrirlos al cierre del ejercicio:

• Facturas duplicadas. El clásico. Una sincronización que se ejecuta dos veces, o que reintenta tras un tiempo de espera, puede contabilizar la misma factura dos veces. La solución es una clave de idempotencia, casi siempre el ID de pedido o de factura de PrestaShop, para que el lado contable reconozca y omita una repetición.
• Desviaciones por redondeo. PrestaShop y tu software contable pueden redondear el impuesto por línea frente a por total de forma distinta. Una diferencia de un céntimo en un pedido es ruido; en miles de pedidos se convierte en una conciliación que nunca termina de cuadrar. Decide una vez la regla de redondeo y haz que ambos sistemas coincidan (el modo y el tipo de redondeo de PrestaShop están en Parámetros de la tienda → General).
• Desajuste de moneda. Un cliente paga en GBP y tus libros están en EUR: el asiento necesita tanto el importe en la moneda original como el importe convertido al tipo correcto, o tus informes de moneda extranjera serán ficticios.
• Comisiones de pasarela olvidadas. El porcentaje de una pasarela de pago no es un descuento sobre ingresos: es un gasto. Registra la venta bruta y la comisión por separado, o tus márgenes parecerán mejores de lo que son y tu saldo bancario no cuadrará.
• Reembolsos que desaparecen. El punto donde más a menudo se rompe un proceso manual son los reembolsos. Si los abonos no fluyen automáticamente hacia facturas rectificativas, tus ingresos estarán sistemáticamente sobrevalorados. Automatiza este camino primero, no al final.

Un despliegue sensato, según el tamaño de la tienda

No necesitas la canalización más sofisticada: necesitas una que sea precisa, fiable y ahorre más tiempo del que cuesta mantenerla. Ajusta el esfuerzo al volumen:

• Menos de ~50 facturas/mes: una exportación semanal (CSV/estilo Datev) que tu contable importe es realmente suficiente. No sobrediseñes.
• ~50–500/mes: una sincronización automatizada diaria o una exportación programada, con reembolsos automatizados y una alerta de fallo para detectar una ejecución rota el mismo día, no al cierre de mes.
• 500+/mes: integración casi en tiempo real con idempotencia, registros y monitorización: el volumen en el que un duplicado silencioso o una factura rectificativa omitida resulta lo bastante caro como para justificar la ingeniería.

Y sea cual sea el tamaño: habla con tu contable antes de construir. Pregunta qué plan contable usar, qué códigos fiscales espera, qué formato de exportación importa realmente y si quiere que PrestaShop o su propio sistema controle la numeración de facturas. Después ejecuta la nueva canalización en paralelo con tu proceso actual durante un mes completo y concilia ambos antes de apagar el respaldo manual. El objetivo no es una integración ingeniosa; es un cierre trimestral en el que los libros ya estén cerrados porque cada pedido, reembolso y línea fiscal se tradujo correctamente a la primera.

Preguntas frecuentes

¿El número de factura debe venir de PrestaShop o de mi software contable?

Elige uno como registro principal y mantente firme. Si emites facturas visibles para el cliente en el momento del pedido y la tienda es tu libro de ventas principal, PrestaShop debería controlar la numeración; pero entonces debes controlar estrictamente el prefijo, el formato y la secuencia para que no haya saltos y resista una auditoría (para eso sirven Invoice Number y Order Number). Si tu contable exige emitir todos los documentos legales desde su sistema, deja que los numere y trata el ID de pedido de PrestaShop como metadato, y oculta el PDF del cliente para que ambos documentos no entren en conflicto.

¿Cómo deben llegar los reembolsos a mi software contable?

Como facturas rectificativas, nunca como facturas eliminadas o editadas. Un abono de PrestaShop (OrderSlip / ps_order_slip) se mapea a una factura rectificativa (Xero) o a una nota de crédito (QuickBooks) contra la factura original: mismo importe, mismo tratamiento fiscal, valores negativos. Automatiza este camino primero, porque un proceso manual de reembolsos es la causa más común de que los libros sobrestimen los ingresos.

¿Necesito una suscripción de middleware de pago o basta con exportar un archivo?

Para un contable orientado a exportaciones, Datev en Alemania, JPK en Polonia o cualquiera que diga "mándame simplemente un CSV". , Una exportación programada es exactamente lo que quiere, y un módulo como Invoice CSV List Exporter lo hace sin cuota recurrente y sin que los datos de pedidos salgan de tu servidor. El middleware (Synder, A2X) justifica su suscripción cuando quieres específicamente una sincronización API en vivo y sin intervención con Xero o QuickBooks, con reintentos y registros gestionados por el servicio.

¿Cómo evito contabilizar dos veces una factura cuando una sincronización reintenta?

Usa una clave de idempotencia, casi siempre el ID de pedido o de factura de PrestaShop, para que el lado contable reconozca y omita una repetición. Sin ella, cualquier sincronización que se ejecute dos veces o reintente tras un tiempo de espera puede contabilizar de nuevo la misma factura, y lo descubrirás en la conciliación. Es una decisión de diseño de una línea que evita el fallo más común en integraciones contables.

Mi IVA transfronterizo aparece mal en la contabilidad: ¿dónde suele fallar?

Casi siempre en el mapeo de tipos impositivos o en la falta de la dimensión de país. PrestaShop almacena el destino y la regla fiscal aplicada por factura, pero la integración debe llevar ese país hasta la contabilidad para la declaración OSS, contabilizar las ventas B2B con números de IVA intracomunitario válidos como inversión del sujeto pasivo (no como IVA cero) y tratar las ventas fuera de la UE como exportaciones al 0 % en lugar de descartarlas. Valida los números de IVA en el momento del pedido (Automatic EU VAT Checker comprueba contra VIES) para que cada pedido quede etiquetado correctamente antes de llegar al libro contable.

Lecturas relacionadas

• Cuando tu tienda deja atrás el trabajo manual. Decidir si la integración contable es el primer paso que necesitas
• Conectar PrestaShop con tu ERP, la mitad de stock y compras, con una forma distinta al libro contable
• Zapier y Make para PrestaShop, cuando tu motivo para integrar es una automatización más amplia de la tienda, no el libro contable