Un pago con tarjeta llega a sus libros a través de un informe del adquirente que ya identifica el pedido. Una transferencia de USDC le llega con una dirección, un importe y un hash de transacción, y nada más. La conciliación de pagos cripto funciona cuando la factura incluye la referencia de su negocio, porque la transferencia no puede incluirla.
Esta guía va dirigida a los equipos financieros y de operaciones de comerciantes, PSP y EMI que aceptan stablecoins y liquidan en euros. Enumera los campos que necesita cada registro de factura, explica cómo tratar los pagos parciales y los pagos con una moneda equivocada, cómo alimentan el libro mayor los webhooks y la API, y qué normas de la UE determinan durante cuánto tiempo debe conservarlo todo.
Momentos clave
En resumen
- Una transferencia ERC-20 solo incluye remitente, destinatario e importe. La referencia del pedido debe figurar en la factura, no en el pago.
- Fije el precio de la factura en EUR y registre esa cifra en euros. El importe en cripto es un número derivado que conserva para la pista de auditoría.
- La mayor parte del trabajo está en las excepciones: pagos parciales, facturas caducadas y la moneda equivocada. Revíselas a diario, no al cierre de mes.
- Use el webhook como disparador, vuelva a leer la factura por su ID como fuente de verdad y descargue la lista de facturas cada noche como red de seguridad y como origen de su exportación CSV.
¿Por qué la conciliación de pagos cripto es más difícil que con tarjetas?#
La conciliación de pagos cripto es más difícil porque una transferencia en blockchain no tiene ningún campo para su número de pedido. En Ethereum, el estándar de token ERC-20 (EIP-20) define el evento de transferencia como `Transfer(address _from, address _to, uint256 _value)`: quién envía, quién recibe y cuánto. No hay memo, ni número de factura, ni nombre del cliente.
Los pagos con tarjeta y bancarios funcionan al revés. Una transferencia SEPA tiene un campo de información que el ordenante debe rellenar, y el informe de liquidación de un adquirente enumera cada operación con tarjeta junto a su referencia de comerciante. Su sistema contable concilia usando esa referencia.
Con las stablecoins, aparecen tres dificultades más:
- El importe rara vez es redondo. Una factura de 250 EUR expresada en USDC pasa a ser una cifra como 279,2846 USDC, de modo que dos facturas de importe similar pueden parecer iguales.
- La liquidación no es definitiva de inmediato. Ethereum produce un bloque cada 12 segundos, pero según ethereum.org (página actualizada en octubre de 2026), «un bloque de Ethereum tarda unos 15 minutos en finalizarse». Una transferencia puede ser visible y, aun así, no contar.
- Los pagadores cometen errores. Envían una cantidad insuficiente, envían dos veces, envían una moneda distinta o pagan después de que la factura haya caducado.
Por tanto, el vínculo debe existir antes de que el pagador pague: una factura por pedido, con su ID de pedido y su propia dirección de pago, de modo que cada transferencia entrante llegue a un registro que ya sabe a qué corresponde.
¿Qué campos necesita cada registro de factura cripto?#
Cada factura necesita un conjunto fijo de campos que relacionen cuatro elementos: su pedido, el precio en euros, la transferencia en cadena y el estado final. Si falta alguno, alguien acabará conciliando a mano. La tabla siguiente usa los nombres de campo de la API de facturas de ItisPay; otros proveedores usan nombres distintos para las mismas ideas.
| Campo | Qué contiene | Por qué lo necesita contabilidad |
|---|---|---|
| invoice_id | ID único asignado por el proveedor | Clave primaria de cada búsqueda y de cada fila del libro mayor |
| order_id | Su número de pedido o contrato, único por pedido | El vínculo con su ERP, tienda o CRM; la referencia que las tarjetas le dan gratis |
| order_name | Descripción breve del pedido | Permite a una persona revisar una excepción sin abrir la tienda |
| fiat_amount, fiat_currency | Precio en EUR | La cifra de ingresos que registra |
| currency, crypto_amount | Moneda facturada e importe debido | Muestra lo que se pidió enviar al pagador |
| actual_crypto_amount_paid | Lo que realmente llegó | Detecta pagos insuficientes y excesivos |
| currency_paid | Moneda usada, si es distinta de la facturada | Marca los pagos con moneda equivocada para revisión |
| network, address | Red blockchain y dirección de pago | Demuestra adónde se envió el dinero; necesario para cualquier rastreo o devolución |
| transactions (tx_hash, amount, status) | Una línea por cada transferencia entrante | Una factura puede recibir varias transferencias; cada hash es su prueba en cadena |
| status | new, pending, completed, expired, cancelled, paid_partial | Decide si registra, envía, reclama o cierra |
| created_at, updated_at, expires_at | Marcas de tiempo | Corte al cierre de mes y prueba de cuándo se pagó el pedido |
Dos de estos campos hacen la mayor parte del trabajo. `order_id` es la referencia que una transferencia blockchain no puede llevar, así que asígnela desde su propio sistema y hágala única por pedido, nunca por cliente. La lista `transactions` es importante porque una factura no siempre se paga de una vez: cada transferencia tiene su propia fila con un hash y un estado, de modo que puede ver qué transferencias componen el importe pagado.
Guarde el importe en cripto con todos sus decimales en una columna aparte. Su libro mayor general trabaja en céntimos de euro; las columnas cripto son pruebas, no valores contables.
¿Qué importe en euros se registra en los libros?#
Registre el precio en euros de la factura. Cuando la factura se emite en EUR, el proveedor la convierte en un importe en criptomonedas al tipo de cambio vigente, y el pagador envía ese importe. Si el pago se liquida en euros en su cuenta, la cifra en euros de la factura es su ingreso, y el importe en criptomonedas es un detalle técnico de cómo llegó.
Esta es la principal razón por la que los equipos que aceptan pagos con criptomonedas de forma automática con conversión a EUR rara vez necesitan contabilidad de criptoactivos: no hay ninguna moneda en el balance que valorar al cierre de mes.
Esto cambia si conserva las stablecoins. El Comité de Interpretaciones de las NIIF decidió en junio de 2019 que las tenencias de criptomonedas se rigen por la NIC 2 (existencias) cuando se mantienen para la venta en el curso ordinario del negocio, y por la NIC 38 (activos intangibles) en caso contrario. Su definición de criptomoneda excluye los activos que crean un contrato entre el titular y otra parte. USDC es distinto: Circle declara que es «canjeable 1:1 por dólares estadounidenses», y desde julio de 2024 Circle emite USDC y EURC en la UE como tokens de dinero electrónico, con una licencia de dinero electrónico del regulador francés ACPR. Cómo clasificar una stablecoin en cartera es una cuestión para su auditor. Liquidar a EUR en el momento de la recepción evita el problema.
¿Cómo se gestionan los pagos parciales y las monedas equivocadas?#
Trate cada factura que no esté en `completed` como una excepción con un responsable y un plazo. La mayor parte del esfuerzo de conciliación de pagos con criptomonedas se concentra aquí; una factura pagada en su totalidad se concilia sola.
Esto es lo que significa cada estado para finanzas, usando los estados de ItisPay:
| Estado | Qué ocurrió | Qué hace finanzas | ¿Entregar o liberar? |
|---|---|---|---|
| new | Factura abierta, nada recibido | Nada que registrar | No |
| pending | Se ve una transferencia, aún no es definitiva | Esperar a que cambie el estado | No |
| completed | Pagada en su totalidad | Registrar el ingreso al precio en EUR y liberar el pedido | Sí |
| paid_partial | Ha llegado parte del importe | Pedir el resto, reembolsar o cerrar por acuerdo | Depende |
| expired | Se agotó el tiempo sin pago completo | Cerrar el pedido; revisar transferencias tardías | No |
| cancelled | Usted anuló la factura | Sin asiento; reemitir si el cliente aún quiere pagar | No |
Pagos parciales#
Un pago parcial suele significar que la cartera o el exchange del pagador cobró una comisión del importe, o que el pagador lo escribió mal. ItisPay registra cada transferencia por separado, de modo que una segunda transferencia puede completar la factura. La factura también tiene un ajuste `allowed_error_percent`: una tolerancia pequeña, definida por factura, de forma que un pago que se queda ligeramente corto siga contando como pagado. Defínalo una vez como política, por ejemplo en un nivel que también asumiría en una transferencia bancaria, y no lo cambie caso por caso.
Si el resto nunca llega, decida dentro de un número fijo de días: acepte el déficit y lo dé de baja, reembolse lo recibido o cancele el pedido. Deje constancia de la decisión en el registro de la factura para que el auditor vea por qué un pedido pagado tiene menos dinero respaldándolo.
Moneda equivocada o pago tardío#
Cuando un pagador envía una stablecoin distinta de la facturada, el campo `currency_paid` lo muestra. No lo registre automáticamente: compruebe el importe y el valor en euros, y después acéptelo o reembólselo. Una transferencia a una factura caducada es similar. El dinero está en la cadena de bloques, pero su pedido está cerrado, así que alguien debe decidir si reabre el pedido o devuelve los fondos. Si anula un pedido por su parte, cancele la factura a través de la API (una actualización de estado), para que sus registros muestren que está cerrada antes de que llegue cualquier pago tardío.
¿Cómo deben alimentar los webhooks y la API la conciliación de pagos con criptomonedas?#
Use tres capas: el webhook le indica que algo ha cambiado, una nueva lectura de la factura le indica qué es cierto, y una extracción nocturna de todas las facturas detecta lo que las dos primeras hayan pasado por alto.
- Cada factura puede incluir un `callback_url`; el proveedor envía allí las actualizaciones de estado. Trate el mensaje como un disparador, no como prueba.
- En cada webhook, llame a `GET /invoices/{invoice_id}` y actúe según el estado y los importes de esa respuesta. Esto le protege frente a llamadas falsificadas o reproducidas a su endpoint, ya que la llamada a la API requiere su clave de API.
- Haga el manejador idempotente: el mismo estado puede llegar dos veces. Asocie su asiento en el libro mayor a `invoice_id` más el estado, de modo que una repetición no cambie nada.
- Cada noche, liste las facturas ordenadas por `updated_at`, de la más reciente a la más antigua, y pagine hasta su última ejecución; además, vuelva a comprobar cada factura que siga en `new`, `pending` o `paid_partial`. Compárelas con su libro mayor. Cualquier factura pagada en los registros del proveedor pero abierta en los suyos es una excepción.
Para las pruebas, ItisPay dispone de un endpoint que simula un cambio de estado de una factura, y otro que reenvía el último webhook por `invoice_id` u `order_id`. Use el reenvío cuando su servidor haya estado caído. Los equipos que canalizan varios métodos de pago a través de una capa de orquestación de pagos aplican el mismo patrón a cada vía.
¿Cómo se construye una exportación CSV para contabilidad?#
Construya la exportación a partir de la API de lista de facturas, con una fila por factura y una fila por transferencia. En ItisPay, `GET /invoices` filtra por estado, moneda y fecha de creación, ordena por fecha o importe, y devuelve hasta 100 facturas por página junto con el número de páginas. Un pequeño script puede recorrer las páginas de un día o de un mes y escribir las columnas de la tabla de campos anterior.
Dos archivos funcionan mejor que uno:
- `invoices.csv`: invoice_id, order_id, fiat_amount, fiat_currency, currency, crypto_amount, actual_crypto_amount_paid, status, created_at, updated_at. Es el archivo que importa el contable y que cruza con las ventas.
- `transfers.csv`: invoice_id, tx_hash, amount, currency, transfer status, time. Es el archivo de evidencias para el auditor.
Importe el archivo de facturas en su herramienta contable como haría con un informe de liquidación de pagos con tarjeta: una línea por pedido, en euros, con el ID del pedido como clave de cruce.
¿Qué normas de la UE configuran los registros de pagos con criptomonedas?#
Tres normas de la UE establecen el contexto. Ninguna de ellas convierte a un comerciante en un proveedor de servicios de criptoactivos (CASP), pero sí determinan qué datos existen y durante cuánto tiempo se conservan.
- Reglamento sobre transferencias de fondos (UE) 2023/1113. Desde el 30 de diciembre de 2024, el proveedor de servicios de criptoactivos del ordenante debe asegurarse de que cada transferencia vaya acompañada de información sobre el ordenante y el beneficiario, como nombres y direcciones de cartera (artículo 14). Los datos viajan junto a la transferencia, no dentro de ella. En las transferencias superiores a 1.000 EUR desde o hacia una cartera autoalojada, el proveedor de la parte correspondiente debe evaluar si esa cartera pertenece a su propio cliente (artículos 14 y 16). Esta es tarea del proveedor autorizado y es una de las razones por las que un pago puede quedar en revisión.
- Conservación de registros. Con arreglo a la Directiva AML vigente (UE) 2015/849, artículo 40, los sujetos obligados conservan los registros de transacciones durante cinco años tras la finalización de la relación de negocio o tras la realización de la operación. El nuevo Reglamento AML (UE) 2024/1624 mantiene el plazo de cinco años (artículo 77) y se aplica desde el 10 de julio de 2027.
- DAC8, Directiva (UE) 2023/2226. Desde el 1 de enero de 2026, los proveedores de servicios de criptoactivos comunican a las autoridades fiscales las operaciones con criptoactivos de sus usuarios. Sus propios registros deben coincidir con lo que comunica su proveedor.
Si trabaja a través de un socio autorizado, el socio asume las obligaciones de CASP en virtud de MiCA y de estas normas, como se explica en nuestra guía sobre la licencia de CASP según MiCA. Usted sigue conservando sus registros de pedidos y su parte del rastro de las operaciones.
¿Dónde sigue necesitando una persona la conciliación de criptomonedas?#
La automatización se encarga del caso pagado en su totalidad. El resto requiere un responsable designado y una breve política por escrito.
Dónde no ayuda
- Los reembolsos son nuevas transferencias salientes, no anulaciones. Requieren un pago a una dirección o IBAN, y sus propios registros.
- Un pagador que envía desde una cuenta de un exchange no siempre puede identificarse por la dirección de envío. Concilie siempre por la factura, nunca por el remitente.
- Los pagos a una factura caducada, los pagos duplicados y las monedas incorrectas requieren una decisión humana.
- Las comisiones de red y los redondeos generan pequeñas diferencias. Fije una tolerancia una sola vez y manténgala.
Una rutina diaria de conciliación de pagos con criptomonedas en cinco pasos#
Una rutina diaria breve convierte el cierre mensual en una mera formalidad:
- Extraiga de la API las facturas creadas o actualizadas desde la última ejecución y actualice los archivos de facturas y transferencias.
- Compruebe que cada factura `completed` tiene un pedido pagado correspondiente en su tienda o ERP, y viceversa.
- Gestione la lista de excepciones: `paid_partial`, pagos a facturas caducadas, monedas incorrectas. Cierre cada una con una decisión por escrito.
- Concilie la liquidación en euros de su cuenta bancaria con la suma de las facturas completadas del periodo. La liquidación en un IBAN es el punto donde los IBAN virtuales ayudan a separar los flujos por línea de negocio.
- Archive ambos archivos durante al menos cinco años.
Si quiere aceptar stablecoins y recibir euros sin construir esta infraestructura por su cuenta, ItisPay ofrece la API, la facturación y los datos de conciliación: IDs de factura y de pedido, hashes por transferencia, estados y webhooks. La obtención de licencias, el KYC y la liquidación en su IBAN se gestionan a través de nuestro socio de la UE con licencia como CASP + entidad de pago, y la mayoría de los equipos pasan del KYB a la primera transacción en menos de una semana.
Este artículo tiene únicamente fines informativos y no constituye asesoramiento jurídico ni regulatorio.
