¿Puede Tresora enviar pagos a nuestros bancos?

Sí. Eso es el módulo. Tresora construye la instrucción, la lleva por las aprobaciones que exige tu política y la envía al banco por el canal que use ese banco. El dinero se queda en tus cuentas y bajo tus contratos, y no se envía nada que no hayas aprobado.

¿Quién decide la ruta de aprobación?

Tú, y la cambias sin nosotros. Los pasos, los importes a partir de los que muerden, qué roles se sientan en ellos y quién puede lanzar son configuración. Cada cambio sobre cualquiera de ellos queda registrado en Cambios de autorización, con la persona que lo hizo.

¿Qué formatos y canales de pago usáis?

pain.001 para transferencias SEPA y para cualquier otro banco ISO 20022, pain.008 para adeudos directos y MT101 donde el banco lo prefiere, por EBICS, SWIFT, host-to-host o la API del banco. El estado vuelve en pain.002 y el cargo en camt.054 o en el propio extracto. Si alguno de tus bancos quiere otra cosa, la añadimos.

¿Qué pasa cuando un banco rechaza uno?

El rechazo cae sobre la orden con el código de motivo del propio banco, y la orden sigue abierta. No se reintenta nada por su cuenta. Tu posición y tu previsión mantienen ese dinero como no pagado, porque leen la misma orden y no un informe sobre ella.

¿Puede lanzar un pago quien ve la posición de caja?

Solo si le has dado ese derecho. Ver y lanzar son derechos distintos en Roles y permisos, y una persona puede tener uno sin el otro. Cada lanzamiento queda escrito en el Registro de actividad con el nombre de quien lo hizo, y cada cambio sobre quién tiene qué derecho también.

Ejecución y control

Ningún pago sale sin tus aprobaciones. Después Tresora instruye a tus bancos.

Lee lo que tu mayor ya tiene por pagar, construye el fichero que acepta cada banco, lleva cada orden a las personas que marca tu política, envía la instrucción y recoge la respuesta que vuelve. Remesas y órdenes sueltas, sobre las mismas cifras conciliadas que lee el resto de pantallas.

Solicitar una demo

Pagos pendientes de revisión · una remesa

Importe de la remesa

EUR 4.823.500

En 208 pagos

Transferencias a proveedores 168 pagos: EUR 2.940.600
Transferencias transfronterizas 31 pagos: EUR 704.900
Traspasos entre tus propias cuentas 9 pagos: EUR 1.178.000

Retenidas para revisión4

De dónde sale

¿Qué hace exactamente el módulo de pagos?

Construye la instrucción que tu banco necesita a partir de lo que ya tienen tus propios sistemas, la pasa por tus aprobaciones, la envía y deja la respuesta del banco sobre esa misma orden. Entran cuatro fuentes, y las cuatro son tuyas.

Lo que tu mayor tiene por pagar: Las facturas y los apuntes que tu ERP ya ha aprobado para pago, con la sociedad, el importe, la divisa y la fecha valor que llevan allí.
De qué cuenta sale: Tu catálogo de cuentas bancarias decide la cuenta ordenante de cada sociedad: el contrato bajo el que está, la divisa que mantiene y el canal por el que responde ese banco.
A quién se paga: Tus contrapartes — el beneficiario, los datos de cuenta que tienes registrados, los nombres y referencias con los que ha aparecido, y cada pago anterior que el grupo le hizo.
Lo que permite tu política: Pasos de aprobación, los importes a partir de los que muerden, quién puede lanzar y quién solo puede mirar. Es configuración del producto, no algo que haya que desarrollar.

El fichero que sale es el que acepta ese banco. pain.001 para transferencias SEPA y para cualquier otro banco ISO 20022, pain.008 para adeudos directos, MT101 donde el banco lo sigue pidiendo, por EBICS, SWIFT, host-to-host o la propia API del banco. Un fichero por cuenta, partido como lo quiera ese banco. Si alguno de tus bancos manda o admite algo que no está aquí, lo añadimos.

Lo que sigue siendo tuyo

El dinero se queda en tus cuentas, a tu nombre y bajo tus contratos con tus bancos. No se mueve nada que no hayas autorizado, y ninguna instrucción llega a un banco sin las aprobaciones que exige tu política.

La ruta de aprobación

¿Quién tiene que aprobarlo antes de que salga?

Quien diga tu política, y a partir del importe que diga tu política. Un paso por rol, un límite por paso, y una sociedad o una cuenta pueden llevar el suyo. La remesa se para en el paso al que ha llegado y dice a quién está esperando.

Controller de la sociedad: Todas las órdenes nacidas en esa sociedad, valgan lo que valgan. El primer paso suele ser quien conoce la factura, no quien conoce el saldo. Dada
Tesorería del grupo: La remesa entera, cuando cada sociedad ya ha despachado la suya. Es el paso que decide si sale hoy o mañana, porque es el que tiene la posición delante. Dada
Dirección financiera: Cualquier orden por encima del límite fijado para la sociedad que paga. Ese límite se fija por sociedad, por cuenta o por contraparte; una remesa sin nada por encima nunca llega a este paso. Pendiente

Quién puede hacer qué

Los derechos de aprobación se fijan en Roles y permisos y en ningún otro sitio, y cambiarlos es a su vez un evento registrado en Cambios de autorización: quién cambió los derechos de quién, y cuándo. Ver la posición del grupo no da derecho a lanzar un pago — son dos derechos distintos, y una persona puede tener uno sin el otro. Cada lanzamiento, retención y rechazo queda en el Registro de actividad con el nombre de quien lo hizo.

Los controles

¿Qué frena un pago que no debería salir?

Un conjunto de comprobaciones que corren sobre cada orden antes de poder lanzarla, y cada una compara esa orden con algo que ya tienes tú. La orden que falla alguna se queda donde está, con la comparación que la retuvo escrita encima. Nadie tiene que darse cuenta.

Los datos bancarios del beneficiario: Contra la cuenta que tienes registrada para esa contraparte, y contra la cuenta a la que fue de verdad cada pago anterior. Un primer pago a datos nuevos es una decisión que toma alguien, nunca lo que pasa por defecto.
El importe: Contra lo que se le ha pagado antes a esa contraparte, y contra el límite fijado para la sociedad que paga. La orden que pasa los dos sigue por la ruta de aprobación; la que no pasa ninguno no llega a ella.
El duplicado: Contra las demás órdenes de la remesa, y contra lo que ya salió con la misma referencia de mensaje: el MsgId de un pain.001, la referencia del ordenante de un MT101. Pagar una factura dos veces es el error más caro de este módulo y el más fácil de cometer.
El beneficiario en sí: Contra tus contrapartes: el número de cuenta, los alias, los nombres con los que se ha contabilizado en cada sociedad. Un beneficiario al que el grupo no ha pagado nunca queda marcado justo como eso.

Órdenes de pago · retenidas para revisión

Importe de la orden

EUR 96.400

Transferencia a proveedor, desde una cuenta en euros

Datos bancarios del beneficiario: CAMBIADOS
Importe frente a este beneficiario: POR ENCIMA
Duplicado en esta remesa: SIN DUPLICADO
Beneficiario en tus registros: CONOCIDO

Retenidas en esta remesa · 4 órdenesEUR 268.300

Y la comprobación que corre después de salir

Una conexión con el banco puede caerse cuando la petición ya ha salido, y entonces la respuesta honesta es que todavía nadie lo sabe. Tresora no la vuelve a enviar por su cuenta. La remesa se para, la orden dice por qué, y una persona confirma con el banco qué recibió de verdad. Pagar dos veces a un proveedor es peor que pagarle tarde.

La respuesta de vuelta

¿Cómo sabes que el banco lo ha pagado?

Porque el banco lo dice dos veces, y las dos respuestas caen sobre la misma orden. Primero el informe de estado, instrucción a instrucción, con el motivo del propio banco cuando rechaza alguna. Después el cargo, en el extracto, casado con la orden que lo provocó.

Conciliación de pagos · hoy

Instrucciones enviadas

204

En 5 ficheros, uno por cuenta

Aceptadas por el banco: 202
Rechazadas, con el motivo del banco: 2

Casadas con el cargo · 197 pagosEUR 4.206.800

El informe de estado del banco: pain.002, leído instrucción a instrucción y no fichero a fichero: aceptada, aceptada con cambios, o rechazada con el código de motivo del banco y el texto que mandó con él.
El cargo en el extracto: camt.054 cuando el banco lo manda, y el propio apunte en camt.053, MT940 o el formato que use ese banco. Es el hecho que prueba que el dinero salió, y no es el mismo hecho que la aceptación.
La casación con la orden: Por las referencias que viajaron en el fichero: el end-to-end, el identificador de instrucción, el UETR, la referencia de operación del propio banco. Lo que hizo el banco y lo que dice tu mayor dejan de ser dos preguntas con dos respuestas.

Un rechazo no se pierde en un correo. Se queda sobre la orden con el motivo del banco encima, y la posición, la previsión y el cierre siguen contando ese dinero como no pagado — porque los tres leen la misma orden y no una copia de ella.

Alrededor de la mesa

¿Quién trabaja aquí todos los días?

Tres mesas, tres pantallas distintas, una sola remesa. El centro de servicios la monta y resuelve lo que un control retuvo. Tesorería la lanza y ve llegar las respuestas. El controller no la abre nunca y aun así ve el resultado, porque los cargos que produjo ya están casados cuando empieza el cierre.

Para quién es

De qué lee y a qué alimenta

Antes de que preguntes

Las preguntas que siempre recibe este módulo.

01¿Puede Tresora enviar pagos a nuestros bancos?: Sí. Eso es el módulo. Tresora construye la instrucción, la lleva por las aprobaciones que exige tu política y la envía al banco por el canal que use ese banco. El dinero se queda en tus cuentas y bajo tus contratos, y no se envía nada que no hayas aprobado.
02¿Quién decide la ruta de aprobación?: Tú, y la cambias sin nosotros. Los pasos, los importes a partir de los que muerden, qué roles se sientan en ellos y quién puede lanzar son configuración. Cada cambio sobre cualquiera de ellos queda registrado en Cambios de autorización, con la persona que lo hizo.
03¿Qué formatos y canales de pago usáis?: pain.001 para transferencias SEPA y para cualquier otro banco ISO 20022, pain.008 para adeudos directos y MT101 donde el banco lo prefiere, por EBICS, SWIFT, host-to-host o la API del banco. El estado vuelve en pain.002 y el cargo en camt.054 o en el propio extracto. Si alguno de tus bancos quiere otra cosa, la añadimos.
04¿Qué pasa cuando un banco rechaza uno?: El rechazo cae sobre la orden con el código de motivo del propio banco, y la orden sigue abierta. No se reintenta nada por su cuenta. Tu posición y tu previsión mantienen ese dinero como no pagado, porque leen la misma orden y no un informe sobre ella.
05¿Puede lanzar un pago quien ve la posición de caja?: Solo si le has dado ese derecho. Ver y lanzar son derechos distintos en Roles y permisos, y una persona puede tener uno sin el otro. Cada lanzamiento queda escrito en el Registro de actividad con el nombre de quien lo hizo, y cada cambio sobre quién tiene qué derecho también.

Trae una remesa que ya hayas hecho.

Mándanos una remesa que enviaste el mes pasado y los ficheros con los que te contestaron tus bancos. Te enseñamos esa misma remesa aquí: las aprobaciones que habría necesitado, la orden que un control habría retenido y las confirmaciones cayendo sobre ella.

Solicitar una demo Ver todo el producto

No se envía nada a tus bancos durante una demo. El módulo se enciende cuando tú lo digas.