Revolución financiera: informes avanzados para propietarios de tiendas PrestaShop

Última revisión: junio de 2026, las rutas de campos del back office y los nombres de tablas que aparecen abajo se aplican a PrestaShop 1.7, 8 y 9; las etiquetas de menú cambian ligeramente entre versiones, por lo que el texto exacto en tu administración puede variar.

PrestaShop te dirá sin problema cuánto has vendido. Abre Estadísticas (el controlador AdminStats, dentro del menú Panel de control / Estadísticas según tu versión) y verás ventas a lo largo del tiempo, productos más vendidos, desglose por transportista, un panel de ventas y pedidos, y una lista ordenable de los más vendidos. Lo que ninguna de esas pantallas te dirá es la cifra que decide si tu tienda es realmente un negocio: cuánto dinero te quedas. Los ingresos son lo que PrestaShop mide por defecto. El beneficio es lo que llevas a casa, y ambos se separan mucho más de lo que la mayoría de comerciantes cree. Este artículo trata de cerrar esa brecha: los informes financieros que necesita una tienda PrestaShop para gestionarse por margen en lugar de por facturación, qué te ofrece el back office, dónde se queda corto y cómo llegar al beneficio real por producto, por pedido y por cliente.

Primero, una frontera clara para que este artículo no se salga de su terreno. Esto son informes financieros: dinero que entra, dinero que sale y lo que queda. No es analítica web. De dónde vienen tus visitantes, cómo se comportan en la página, qué fuente de tráfico convierte. Eso es otra disciplina, y la cubrimos en qué medir y qué ignorar y en las métricas de GA4 que de verdad importan. Aquí nos quedamos en la cuenta de resultados.

Por qué las estadísticas nativas de PrestaShop no pueden decirte si eres rentable

El motor nativo de Estadísticas está construido alrededor de ingresos y volumen, porque eso es lo que vive de forma limpia en las tablas de pedidos. Cuando PrestaShop registra una venta, guarda el precio que pagó el cliente, el impuesto, el envío que se le cobró y el estado del pedido. Pero no guarda, en ninguna forma útil para informes, lo que ese pedido te costó. Ese coste está disperso en lugares que las pantallas de Estadísticas nunca conectan:

• Coste mayorista. PrestaShop sí tiene un campo para ello, wholesale_price en el producto, configurado en Catálogo → Productos → [producto] → Precio → Precio de coste, almacenado en ps_product y copiado a ps_order_detail.original_wholesale_price en el momento de la venta. El problema: casi nadie lo rellena y, aun cuando se rellena, los lugares nativos donde aparece, la cifra de margen de beneficio en Estadísticas → Estadísticas del catálogo y la columna de beneficio por producto en Estadísticas → Productos más vendidos / Detalles del producto. Son vistas agregadas o combinadas por producto, nunca por pedido ni por cliente.
• Comisiones de procesamiento de pago. El 1,4–3% que se queda Stripe, PayPal o el procesador de tarjetas nunca entra en PrestaShop. Un pedido de 100 € se registra como 100 € de ingresos, aunque a tu cuenta hayan llegado 97,10 €.
• Coste real del envío. El pedido guarda lo que el cliente pagó por el envío, nunca lo que el transportista te cobró. Ofrece envío gratuito y el total nativo muestra ingresos de envío de cero y un coste de cero, cuando en realidad pagaste 6 € al mensajero.
• Reembolsos y devoluciones. Un pedido reembolsado puede seguir en un estado que cuenta como ingreso "válido" según tu configuración de estados de pedido, inflando discretamente la facturación.

Así que la cifra nativa de "margen de beneficio" sirve como orientación rápida para una comprobación de sentido común, pero no para tomar decisiones. No puede decirte cuál de dos productos deberías promocionar, porque no ve que uno arrastra una comisión de tarjeta de 2 € y una tasa de devolución del 30%, mientras que el otro se envía libre de esas cargas.

Los ingresos son la cifra más engañosa de tu tienda

Imagina dos tiendas PrestaShop una al lado de la otra. La tienda A factura 50.000 € al mes; la tienda B, 20.000 €. El panel nativo hace que A parezca la clara ganadora. Ahora añade los costes que PrestaShop no controla: A vende electrónica de bajo margen con una tasa de devolución del 12%, paga un 1,9% en comisiones de tarjeta y subvenciona el envío; B vende productos de marca propia con un margen del 60% y casi sin devoluciones. Haz las cuentas reales y B se queda más euros cada mes. El comerciante que mira la pantalla nativa de Estadísticas optimizaría exactamente la tienda equivocada.

Ese es todo el argumento a favor de los informes financieros en un solo ejemplo. Las métricas que de verdad mueven una tienda son de segundo nivel: solo existen cuando restas el coste a los ingresos:

• Margen bruto por producto, precio de venta menos coste mayorista, menos la comisión de pago, la subvención del envío y los gastos generales proporcionales atribuibles a esa línea. El producto que parece tu estrella en la lista de más vendidos a veces es el que pierde dinero en silencio cuando entran en escena comisiones y devoluciones.
• Contribución por pedido, lo que deja un pedido concreto después de sus propios costes variables. Dos pedidos de 80 € no son iguales si uno se envió gratis a la otra punta del país y el otro fue recogida en tienda.
• Beneficio por segmento de cliente, conectar el valor de vida del cliente con la adquisición. La relación entre lo que vale un cliente y lo que cuesta conseguirlo es un tema aparte; no lo vamos a recalcular aquí, los datos sobre valor de cliente frente a coste de adquisición están en qué medir y qué ignorar.
• Tasa real de devolución por producto y categoría. Una tasa de devolución del 30% no es un superventas, es un defecto o una descripción engañosa que se come tu margen dos veces: pagas el envío de ida, asumes el de vuelta y quizá no puedas revender el artículo.

Qué puedes obtener hoy de PrestaShop, y el muro de las exportaciones

Antes de buscar cualquier cosa extra, conviene saber exactamente hasta dónde llega la herramienta de serie, porque para un catálogo pequeño quizá sea suficiente.

Esa última fila es donde terminan la mayoría de comerciantes: exportando pedidos a una hoja de cálculo, cosiendo a mano las tarifas de comisiones y las facturas de transporte, y reconstruyendo la misma tabla dinámica cada mes. Funciona una vez. No funciona como hábito semanal, y un informe que solo ejecutas cuando estás preocupado es un informe que detecta los problemas con un mes de retraso. El techo nativo honesto es este: PrestaShop puede mostrarte ingresos en un panel y coste solo si te pones a excavar en el Gestor SQL con tus propias consultas. Unir ambos en una vista de beneficio permanente, programada y explorable en detalle es el muro que el back office no te ayuda a cruzar.

Si te manejas bien con el Gestor SQL, de verdad puedes llegar bastante lejos: una consulta que una ps_orders, ps_order_detail y original_wholesale_price te dará un margen bruto real por pedido. Lo que no puedes hacer fácilmente ahí es incorporar datos de costes externos (tu estructura de comisiones de Stripe, tus facturas de transportista), programarlo o entregárselo a un compañero no técnico. Esa es la línea entre una consulta ingeniosa y un sistema de informes.

La consulta del Gestor SQL que te da el margen bruto real por pedido

Aquí tienes una consulta inicial que puedes pegar en Parámetros avanzados → Base de datos → Gestor SQL. Suma los ingresos de cada pedido frente al coste mayorista capturado en el momento de la venta, para que obtengas el margen bruto por pedido, justo lo que las pantallas nativas no te muestran. Ajusta el prefijo de tabla (ps_) si el tuyo es distinto, y el filtro de pedidos válidos para que coincida con tus estados de pedido:

SELECT
    o.id_order,
    o.reference,
    o.total_paid_tax_excl                              AS revenue_excl_tax,
    SUM(od.product_quantity * od.original_wholesale_price) AS cost_of_goods,
    o.total_paid_tax_excl
        - SUM(od.product_quantity * od.original_wholesale_price) AS gross_margin,
    ROUND(
        100 * (o.total_paid_tax_excl
            - SUM(od.product_quantity * od.original_wholesale_price))
        / NULLIF(o.total_paid_tax_excl, 0)
    , 1)                                               AS margin_pct
FROM ps_orders o
JOIN ps_order_detail od ON od.id_order = o.id_order
WHERE o.valid = 1
GROUP BY o.id_order
ORDER BY gross_margin ASC;

Dos advertencias honestas. Esto es solo margen bruto: resta el coste de los productos, pero no las comisiones de pago, el coste real de envío ni las devoluciones, porque PrestaShop no guarda esos datos (ese es precisamente el punto de este artículo). Y solo es tan fiable como tus datos de original_wholesale_price: los pedidos realizados cuando el campo de coste estaba vacío mostrarán un margen del 100% y distorsionarán la lista. Ordenar de forma ascendente (gross_margin ASC) coloca tus peores pedidos arriba, que normalmente es lo primero que quieres revisar.

De los datos a las decisiones: qué cambia cuando puedes ver el beneficio

¿Y eso en qué se traduce? La finalidad de todo esto no es tener un panel más bonito: es que cuatro decisiones cotidianas dejen de ser apuestas:

• Precios. Subir un 5% un producto con buen margen y demanda estable es una decisión segura cuando puedes ver el margen real actual junto a su tendencia de ventas. A ciegas frente al coste, la misma decisión es lanzar una moneda.
• Qué promocionar. Los informes de beneficio suelen reordenar la lista de más vendidos. El campeón por volumen de unidades y el campeón por beneficio con frecuencia son productos distintos, y quieres que el espacio de tu portada, tu inversión publicitaria y tus ofertas de packs apunten al segundo.
• Inventario. Qué reponer, descatalogar o liquidar debería depender del margen, no del volumen. Un producto lento con un margen del 65% quizá merezca más visibilidad; uno rápido con un 4% puede necesitar una subida de precio o una salida discreta.
• Estrategia de descuentos. Una venta flash que registra 10.000 € de ingresos pero 500 € de beneficio después del descuento, las comisiones y el envío no es el éxito que sugiere el gráfico de ingresos. Un informe consciente del margen te lo dice a la mañana siguiente, no al cierre del trimestre.

Cerrar la brecha con el módulo Financial Revolution

Este es el trabajo concreto para el que existe nuestro módulo Financial Revolution: tomar los ingresos que PrestaShop ya registra, permitirte capturar los costes y gastos que nunca controla, y convertir el resultado en una vista permanente de pérdidas y ganancias dentro del back office, sin hoja de cálculo mensual, sin SQL manual. ¿Qué consigues con eso?

• Una vista real de pérdidas y ganancias, no solo un panel de ingresos, ingresos, tus costes capturados y gastos operativos, impuestos/IVA y el beneficio resultante, desglosados por categoría, para que la cifra final que lees sea la que realmente conservas y no una cifra de facturación.
• Seguimiento de costes y gastos que PrestaShop no tiene dónde guardar, registra los costes y gastos generales que la plataforma nunca almacena (comisiones de procesadores de pago, envío real, gastos operativos) y réstalos automáticamente de los ingresos en lugar de pegarlos después en una hoja de cálculo.
• Informes de flujo de caja, impuestos e IVA en un solo lugar, movimientos de caja, informes de impuestos e IVA, facturas y correcciones gestionados dentro del back office en lugar de conciliados a mano después.
• Vive en tu administración, consúltalo desde el back office con la misma cadencia semanal con la que ya revisas pedidos, en lugar de exportar y reconstruir, con exportación CSV cuando necesites entregar las cifras a un contable.

Límite honesto: un módulo de informes informa, no fija tus precios ni te reembolsa las comisiones de tarjeta. Su trabajo es hacer que la cifra real sea imposible de pasar por alto para que tú puedas actuar. Y solo es tan preciso como los datos de coste que tiene detrás, que es el siguiente punto.

Hazlo fiable: rellena primero los datos de coste

En los informes financieros, si entran datos basura, salen datos basura, y la razón más común por la que un informe de beneficio parece incorrecto son los campos de coste vacíos. Antes de confiar en cualquier cifra de margen, nativa o de módulo, haz el trabajo de base poco vistoso:

• Rellena el precio mayorista / precio de coste en cada producto (Catálogo → Productos → Precio → Precio de coste). Edítalo en masa o impórtalo mediante la importación de catálogo si tienes cientos de SKU; un informe de margen sobre campos de coste medio vacíos es peor que no tener informe, porque parece autorizado y no lo es.
• Conoce tu estructura real de comisiones, el porcentaje y la comisión por transacción reales que cobra tu proveedor de pago, que puedes leer en un extracto de Stripe o PayPal, no en la tarifa anunciada.
• Obtén tus costes reales de transportista, no el precio de envío visible para el cliente, a partir de tus facturas de mensajería, especialmente si ofreces envío gratuito o tarifa plana, donde la cifra pagada por el cliente no te dice nada.
• Ordena tus estados de pedido para que los pedidos reembolsados y cancelados no se cuenten silenciosamente como ingresos válidos. Comprueba qué estados están marcados como logable/pagados en Parámetros de tienda → Configuración de pedidos → Estados.

Construye el hábito de revisar informes

El informe más preciso del mundo no vale nada si nadie lo abre. Las tiendas que mejoran de forma acumulativa son aquellas donde una cifra, no una corazonada, zanja la discusión, y eso solo ocurre con ritmo:

• Semanalmente: beneficio total (no ingresos), tus mejores y peores productos por margen, y cualquier oscilación que merezca una segunda mirada. Cinco minutos desde el back office.
• Mensualmente: tendencias y estacionalidad, y si una iniciativa concreta, un cambio de precio, un nuevo proveedor, una promoción, movió realmente el beneficio y no solo los ingresos.
• Trimestralmente: toda la estrategia frente a los datos. Qué categorías se ganan su espacio, qué clientes merece la pena conservar, dónde está el peso muerto del catálogo.

PrestaShop mide ingresos de serie porque los ingresos son la cifra fácil de guardar. El beneficio es la cifra que dirige el negocio, y llegar a él significa restar los costes que la plataforma dispersa o ignora: coste mayorista, comisiones, envío real, devoluciones. Ya llegues con una consulta cuidadosa en el Gestor SQL, una hoja de cálculo disciplinada o un módulo que haga la unión por ti, la disciplina es la misma: gestiona por lo que conservas, no por lo que facturas, y revísalo con suficiente frecuencia para detectar la caída antes de que ya tenga un trimestre.

Preguntas frecuentes

¿Por qué el margen de beneficio nativo de PrestaShop parece incorrecto o vacío?

Casi siempre porque el campo de precio de coste está vacío. El margen de Estadísticas → Estadísticas del catálogo de PrestaShop se calcula a partir de wholesale_price, y si nunca lo rellenaste en tus productos, la cifra no significa nada. Incluso cuando está rellenado, el dato nativo es un único porcentaje global combinado que ignora comisiones de pago, coste real de envío y devoluciones, así que sirve como comprobación aproximada, pero no para decidir qué producto promocionar. Rellena primero los precios de coste; después decide si la vista nativa basta o necesitas detalle por pedido.

¿Puedo calcular el beneficio real por pedido sin un módulo?

Sí, para el margen bruto: la consulta del Gestor SQL anterior une ps_orders y ps_order_detail sobre original_wholesale_price y te da margen por pedido. Lo que no puedes hacer en el Gestor SQL sin bastante esfuerzo es incorporar costes externos (tu estructura de comisiones de Stripe, facturas de transportista), programar el informe o entregárselo a un compañero no técnico. Esa brecha, unir datos de costes externos en una vista de pérdidas y ganancias permanente y explorable. Es la línea entre una consulta ingeniosa y un sistema de informes como Financial Revolution.

¿Dónde guarda PrestaShop el precio de coste y cómo lo relleno en masa?

El precio de coste vive en wholesale_price dentro de ps_product (y por combinación cuando lo configuras), editado en Catálogo → Productos → Precio → Precio de coste. En el momento de la venta, PrestaShop lo copia a ps_order_detail.original_wholesale_price, por eso los pedidos históricos conservan el coste que era válido cuando se realizaron. Para cientos de SKU, rellénalo mediante la importación CSV del catálogo en lugar de hacerlo a mano, y recuerda que los pedidos realizados antes de rellenarlo no mostrarán coste, así que no confíes en el margen de pedidos antiguos.

¿Financial Revolution registra automáticamente las comisiones de pago y los costes de envío?

Te da el lugar donde registrarlos y los resta automáticamente de los ingresos una vez introducidos, pero no puede leer por ti tu extracto de Stripe ni la factura del transportista. El trabajo del módulo es capturar los costes que PrestaShop no tiene dónde guardar (comisiones del procesador, envío real, gastos operativos) e incorporarlos a una cuenta de pérdidas y ganancias del back office para que dejes de reconstruir una hoja de cálculo. La precisión sigue dependiendo de que introduzcas tu estructura real de comisiones y tus costes de transportista; si entran datos basura, salen datos basura también aquí.

¿Es lo mismo que mis datos de GA4 o de analítica?

No, y confundirlos es un error común. Esto son informes financieros: dinero que entra, dinero que sale y lo que queda. GA4 y herramientas similares son analítica web: de dónde vienen los visitantes, cómo se comportan, qué canal convierte. Responden a preguntas distintas y ninguna sustituye a la otra. Para la parte de analítica, empieza por qué medir y qué ignorar y las métricas de GA4 que de verdad importan.