Automatizar rendiciones de gastos: plataforma o integración

Esta guía está dirigida a Finanzas y Operaciones con un equipo IT que participa de la compra. No trata la recepción de facturas de proveedores ni el cruce de movimientos bancarios: esos procesos tienen otros controles de captura y conciliación. Acá la unidad de trabajo es el gasto rendido por una persona, dentro de una política de la empresa.

Hay plataformas que ya cubren gran parte del recorrido. Mendel Argentina presenta reglas de gasto, aprobaciones e integración con ERP; SAP Concur México ofrece captura, revisión y reembolso. Esas ofertas no prueban compatibilidad con tu versión del sistema ni que necesites desarrollo adicional. Consultamos las fuentes el 6 de noviembre de 2026.

La decisión empieza por el trabajo pendiente. Una plataforma puede ser suficiente si la política y la forma de rendir encajan en sus funciones. Una integración tiene sentido si ya existe un registro confiable de gastos aprobados y el problema es volver a cargarlos en contabilidad. Un desarrollo propio requiere justificar qué regla o experiencia de uso queda fuera de las opciones existentes.

Antes de elegir proveedor, pedí una demostración sobre un ejemplo ficticio representativo: gasto válido, comprobante repetido y gasto devuelto para corregir. Si la herramienta ya permite resolverlos y exportar el resultado que tu ERP necesita, el alcance puede reducirse a configuración o conexión. No hace falta reconstruir todo el circuito para contratar un tramo.

Armá una ficha con persona, sociedad, fecha del gasto, moneda, importe, categoría, centro de costo, motivo, comprobante y referencia de la rendición. Finanzas define qué campos son obligatorios y quién puede verlos. Si hay varias monedas, acordá la fuente y fecha del tipo de cambio y conservá tanto el importe original como el criterio de conversión.

Separá los estados del negocio: borrador, enviado, devuelto, aprobado, pendiente de contabilización, contabilizado y reembolsado. Adaptá los nombres al proceso real. Aprobar un gasto no significa que se haya contabilizado, y contabilizarlo no demuestra que el empleado recibió dinero. Cada transición necesita responsable y evidencia.

La lectura automática de un comprobante puede proponer campos; las reglas de política determinan si la rendición puede avanzar. Una lectura dudosa, una categoría desconocida o una diferencia de importe debe quedar visible para revisión. El proveedor tiene que mostrar cómo una corrección conserva el documento original y el historial, sin dar por válida una deducción fiscal solo porque el archivo fue leído.

Pedí el método de conexión disponible para tu plan y tu versión del ERP, los permisos que requiere, los campos que intercambia y la evidencia de recepción. El soporte de Rindegastos documenta API, servicios web, FTP y archivos; limita la API a cuentas Empresa e indica que algunas alternativas llevan desarrollo asociado. Tener acceso a una plataforma no equivale a tener resuelta su integración.

Definí cómo se mapean empleado, sociedad, categoría y centro de costo al destino. Un gasto con un centro inexistente debe quedar pendiente con un motivo que Finanzas entienda. El flujo también necesita conservar el identificador del asiento o registro devuelto por el ERP, para comprobar qué se creó y dónde.

Una respuesta de aceptación puede preceder al resultado. HTTP 202 indica que la solicitud fue aceptada para procesarse; no confirma su finalización. Si tu conexión funciona así, pedí seguimiento hasta el resultado contable y un estado visible cuando no se pueda confirmarlo. Esta distinción no obliga a usar una API asíncrona: aplica cuando el sistema elegido la utiliza.

Hay dos problemas distintos: presentar dos veces el mismo comprobante y ejecutar dos veces una contabilización o un reembolso. Una comparación de archivos puede ayudar con el primero, pero no resuelve el segundo. Acordá con IT una referencia estable por gasto y operación, y cómo el destino reconoce que una solicitud ya fue aplicada.

Cuando una conexión agota la espera, puede haber ocurrido el registro aunque el emisor no haya recibido la respuesta. Antes de repetir una escritura, el flujo debe consultar o conciliar su resultado según lo que permita el sistema. Si no puede comprobarlo, el caso queda en revisión; un reintento automático a ciegas no es una recuperación aceptable.

Las correcciones posteriores a la aprobación también necesitan una regla. Cambiar importe, moneda, destinatario o centro de costo debería exigir la revisión que Finanzas determine y conservar el valor anterior. Definí qué ocurre si el gasto ya se contabilizó o reembolsó: una edición de pantalla no revierte por sí sola una operación del sistema contable o del banco.

Una empleada presenta un comprobante de traslado y lo asigna al centro de costo de su área. El sistema propone los datos, ella revisa y envía. La persona autorizada aprueba; el flujo intenta registrarlo en contabilidad. Este ejemplo es ilustrativo: no describe un cliente ni un resultado de DuoTach.

El ERP recibe la operación, pero la conexión pierde la respuesta. La rendición queda como pendiente de confirmación, con su referencia conservada. El responsable consulta el destino y encuentra el registro; lo vincula a la rendición sin crear otro. El estado puede pasar a contabilizado. El reembolso sigue pendiente hasta que el mecanismo de pago autorizado aporte su propia confirmación.

Después, la empleada vuelve a subir el comprobante. El sistema señala la posible repetición y lo vincula con la rendición anterior para revisión. La prueba pasa si no genera otra contabilización ni otro reembolso, y una persona puede explicar la secuencia mirando el historial. Esa evidencia es más útil para comparar proveedores que ver una captura exitosa sin excepciones.

Acordá el conjunto de pruebas antes de desarrollar y usá comprobantes ficticios o datos autorizados en un entorno de prueba. Finanzas verifica política y resultado; IT verifica permisos, conexión y recuperación. La aprobación de ambas áreas evita cerrar la entrega solo porque una pantalla funciona.

Incluí gasto válido, moneda incorrecta, comprobante ilegible, repetición, aprobador sin permiso, centro inexistente y destino no disponible. Sumá una escritura aplicada cuya respuesta se pierde y una corrección posterior a la aprobación. Para cada caso, la propuesta debe indicar estado esperado, responsable de resolverlo y prueba de que no se duplica la operación.

Comprobá además que cada empleado vea únicamente lo que le corresponde y que una persona sin rol no pueda aprobar, cambiar políticas o consultar comprobantes de otras áreas. El historial debería permitir reconstruir quién aprobó qué versión del gasto y qué sistema confirmó el resultado.

Pedí partidas separadas para licencias, configuración de política, interfaz de carga si hace falta, conexión al ERP, tratamiento de excepciones, pruebas, documentación y soporte. Aclarar qué queda fuera permite comparar alcances: tarjetas, pagos bancarios, nómina, viajes y validaciones fiscales pueden requerir proveedores, permisos o trabajo adicional.

La medición empieza con una línea base: tiempo desde envío hasta aprobación, rendiciones devueltas, casos pendientes de contabilización y tiempo de resolución. Compará después un período equivalente con un volumen y mezcla de casos conocidos. Una caída del tiempo no demuestra ahorro por sí sola si se excluyeron los casos difíciles.

DuoTach ofrece automatización e integración de sistemas. Si ya tenés una plataforma de gastos y el tramo pendiente es conectarla con tu operación, podés consultar por esa integración. Indicá herramienta, ERP y versión, vía de conexión conocida, circuito de aprobación y punto donde hoy vuelven a cargar datos. El alcance y su viabilidad se definen antes de comprometer una implementación; no prometemos compatibilidad con cualquier sistema ni un resultado financiero sin medirlo.