Conectar el TPV con la contabilidad en un comercio de Andorra

Cada principio de mes, alguien de tu comercio abre el informe del TPV, abre la contabilidad y empieza a buscar los céntimos que faltan. Suele ser una persona cara para esa tarea: tú, tu gestora o un empleado de confianza. Aquí verás por qué los totales no cuadran, qué tiene que soltar el TPV para que la contabilidad lo absorba sin tocar nada, cómo entra el IGI en el cuadro y qué preguntar al proveedor antes de firmar.

Por qué los totales nunca cuadran a la primera

El TPV registra hechos de caja: lo que se cobró, cuándo y con qué medio. La contabilidad registra hechos económicos: ventas, impuestos, cobros pendientes. Son dos visiones del mismo día, y las diferencias nacen en los casos que se salen del camino feliz.

Los culpables habituales en un comercio son siempre los mismos:

• Devoluciones: se devuelve dinero un día distinto al de la venta, a veces por un medio de pago distinto, y el ticket original sigue en el mes anterior.
• Anulaciones: una venta anulada a mitad de cobro deja un movimiento que unos informes cuentan y otros no.
• Propinas: entran por el datáfono, pero no son venta ni llevan el mismo tratamiento que ella.
• Pagos mixtos: una compra pagada mitad en efectivo y mitad con tarjeta, que según el informe aparece como una línea o como dos.
• Cierres de caja a medias: el turno de tarde cierra al día siguiente, o nadie cierra el domingo, y las ventas caen en el día equivocado.

Ninguna de estas cosas es un error de nadie. Es que cada una se registra en un sitio distinto y el cuadre manual consiste en reconstruir a ojo qué pasó. Mientras eso dependa de una persona con una hoja de cálculo, el cuadre tardará horas y fallará justo cuando haya más trabajo.

Qué datos tiene que soltar el TPV

Para que la contabilidad reciba la información sin intervención, el TPV debe entregar datos estructurados y completos, no un PDF de resumen. Un informe pensado para que lo lea un humano no sirve para que lo lea un programa.

Esto es lo mínimo que deberías exigir por cada movimiento:

• Identificador único del ticket o la operación, que no se repita nunca, ni entre tiendas ni entre TPV.
• Fecha y hora reales de la operación, además de la fecha del cierre de caja al que pertenece.
• Líneas de venta con producto, cantidad, precio e impuesto por línea, no solo el total del ticket.
• Medios de pago separados, con el importe de cada uno cuando el pago es mixto.
• Devoluciones y anulaciones como operaciones propias, enlazadas al ticket original.
• Propinas en un campo aparte, fuera del importe de la venta.
• Tienda, caja y empleado que realizaron la operación.

Si el TPV mezcla estas cosas en un solo total, ningún conector del mundo lo arregla después. La calidad de la integración se decide en lo que el TPV sabe guardar, no en lo que la contabilidad sabe leer.

El IGI: desglosarlo por tipo de producto

El IGI es un impuesto que hay que desglosar en cada venta, y la contabilidad necesita la base y la cuota por separado. Si el TPV solo te da un total con impuestos incluidos, alguien tendrá que recalcular después, y ahí es donde aparecen los céntimos de diferencia.

Lo importante es que el tipo de impuesto viaje con el producto, no con el ticket. Un mismo ticket puede llevar artículos con tratamientos distintos, y el TPV debe registrar para cada línea qué tipo se aplicó. Los tipos concretos y su aplicación a cada categoría consúltalos con tu gestora: son los que ella te confirme, no los que asuma un programa por defecto.

Un ejemplo numérico, solo ilustrativo: un ticket de 100 con impuestos incluidos, con un tipo hipotético del 5 %, se desglosa en una base de 95,24 y una cuota de 4,76. Si el TPV redondea por línea y la contabilidad redondea por ticket, la suma puede diferir en un céntimo. Por eso conviene acordar una sola regla de redondeo y comprobar que ambos sistemas la aplican igual.

Exportar un fichero cada mes o una integración real

Hay dos formas de mover los datos y la diferencia importa más de lo que parece.

La exportación mensual consiste en que alguien descarga un CSV del TPV y lo importa en la contabilidad. Es barata y funciona con cualquier sistema, pero depende de una persona, llega tarde y cada error se descubre semanas después, cuando ya no recuerdas qué pasó aquel martes.

La integración real conecta ambos sistemas por una API o un proceso automático: cada cierre de caja genera su asiento, las devoluciones se enlazan solas y las diferencias aparecen el mismo día, no a final de mes. Cuesta más de montar, pero convierte el cuadre en una excepción que revisas y no en una tarea que ejecutas.

Una buena regla: si tu comercio hace pocas ventas y una sola caja, el fichero mensual aguanta. Si tienes varios días con mucho volumen, devoluciones frecuentes o más de una tienda, la integración se paga sola en horas de trabajo.

Varias tiendas, varios TPV

Con una sola tienda el cuadre es incómodo. Con varias, el problema se multiplica: cada TPV tiene sus cierres, sus devoluciones y su ritmo, y la contabilidad necesita una visión consolidada pero también el detalle por punto de venta.

Lo que debe resolverse desde el principio:

• Identificadores que no choquen entre cajas: dos TPV no pueden generar el mismo número de ticket.
• Una sola configuración de productos e impuestos, compartida, para que el mismo artículo no tenga tratamientos distintos según la tienda.
• Devoluciones entre tiendas: el cliente compra en una y devuelve en otra, y el dinero y el stock deben acabar donde corresponde.
• Cierres por tienda con una hora de corte común, para que los días sean comparables.
• Un cuadro consolidado que permita bajar desde el total de la empresa hasta una caja concreta.

Si tu operativa empieza a parecerse a esto, lo que necesitas ya no es solo un conector, sino una capa central que reciba los datos de todos los TPV y los entregue limpios. Es el tipo de trabajo que encaja en un CRM o ERP a medida, donde ventas, stock y contabilidad hablan el mismo idioma. Si tu comercio es de producto con alta rotación, como las perfumerías, la presión sobre devoluciones y stock hace que esto se note antes.

Qué preguntar al proveedor antes de firmar

El momento de negociar la integración es antes de contratar el TPV, no cuando ya llevas un año con él. Estas son las preguntas que separan a un proveedor que te deja salir de uno que te encierra:

• ¿Tengo acceso a mis datos en bruto? No a un informe, a los datos: ticket por ticket, línea por línea.
• ¿En qué formato? CSV, JSON, API. Pide un ejemplo real con un día de datos y mira si trae el desglose de impuestos por línea.
• ¿Tiene API documentada? Y si se cobra aparte, cuánto y con qué límites de uso.
• ¿Qué pasa con las devoluciones y anulaciones? Pide ver cómo aparecen en la exportación y si quedan enlazadas al ticket original.
• ¿Cómo gestiona el pago mixto y las propinas? Si salen como campos separados o mezclados.
• ¿Qué ocurre si me voy? Si puedo llevarme el histórico completo y en qué formato.
• ¿Quién es el propietario de los datos? Que lo diga el contrato, no el comercial.

Si el proveedor responde con evasivas a la primera, ya tienes la respuesta. Un TPV que no te deja sacar tus datos es una dependencia, no una herramienta.

Y si ya tienes un TPV que no suelta nada

No siempre se puede elegir. Si ya tienes un sistema cerrado, aún quedan opciones: exportaciones programadas, lectura de la base de datos si el proveedor lo permite, o una capa intermedia que normalice lo poco que sí sale. No es lo ideal, pero suele ser mejor que seguir cuadrando a mano.

Hablemos de tu caso

En AndorraDev conectamos TPV, stock y contabilidad en comercios andorranos, desde una tienda hasta varias. Si cada mes pierdes horas cuadrando cifras, hablemos y revisamos qué datos te da hoy tu sistema y qué hace falta para automatizarlo.