Conciliar pagos con criptomonedas consiste en demostrar a qué pedidos corresponde cada cobro verificado y explicar todas las diferencias restantes. El saldo de una billetera, por sí solo, no indica qué vendiste, qué cliente pagó ni si una transferencia correspondía siquiera a una venta.
Utiliza tres registros vinculados: el pedido, el registro de pago del proveedor y la transferencia recibida por tu empresa. Esta guía ofrece a pequeños equipos comerciales un procedimiento de cierre diario, no asesoramiento contable ni fiscal. Los controles son recomendaciones para tus propios registros; no implican que Yolfi exporte, concilie o contabilice pagos automáticamente.
Mantén separados los pedidos, los registros de pago y las transferencias
Un pedido describe el acuerdo comercial. Un registro de pago describe la solicitud y su procesamiento. Una transferencia en la cadena de bloques demuestra un movimiento de activos. Están relacionados, pero no son intercambiables.
Un pedido puede tener varios intentos de pago. Una transacción puede contener varias transferencias de tokens. Un movimiento entre tus propias billeteras no es otro pago de un cliente. Conserva estas relaciones en lugar de forzar cada fila a un modelo de un pedido y un hash.
| Registro | Campos mínimos que debes conservar | Pregunta que responde |
|---|---|---|
| Pedido | Referencia del pedido, referencia del cliente, moneda e importe de la factura, estado del pedido | ¿Cuánto debía el cliente? |
| Solicitud de pago | Referencia del proveedor, pedido vinculado, activo y red solicitados, destino, importe y vencimiento si corresponde | ¿Qué instrucciones se emitieron? |
| Transferencia verificada | Red, identificador del activo, hash de la transacción, posición de la transferencia cuando corresponda, destinatario, importe, bloque y pruebas de confirmación | ¿Qué llegó realmente? |
| Asignación | Referencia de la transferencia, referencia del pedido, importe aplicado, revisor y fecha y hora | ¿Qué cobro liquidó qué obligación? |
| Ajuste | Referencia del reembolso o de la transferencia interna, motivo, aprobación y registro relacionado | ¿Por qué difieren los movimientos de las ventas? |
Guarda los datos personales de los clientes en registros empresariales con control de acceso, no en notas públicas de la cadena de bloques. Nunca almacenes claves privadas ni frases de recuperación en una hoja de conciliación.
Identifica la transferencia, no solo el símbolo o el hash
Para los tokens, conserva la red y la dirección verificada del contrato o de emisión, además del símbolo. Una etiqueta que diga USDC no basta para distinguir activos de distintas cadenas ni un token ajeno que utilice el mismo símbolo. Comprueba los identificadores en una fuente autorizada sobre el activo antes de aceptar los cobros.
Para una transferencia de tokens en EVM, una referencia única práctica combina el identificador de la cadena, el hash de la transacción y el índice del registro, junto con el contrato verificado del token. Un hash de transacción por sí solo es demasiado general cuando una transacción emite varios eventos de transferencia. Otras cadenas necesitan sus propios identificadores de instrucción o evento adecuados; no impongas el formato EVM en todas ellas.
La documentación de Ethereum JSON-RPC distingue los recibos de transacción, el estado y los registros. Para un pago ERC-20, examina el evento de transferencia del token correspondiente: el destinatario principal de la transacción puede ser un contrato, no la dirección de recepción del comercio. Que una transacción se complete correctamente no demuestra, por sí solo, que hayas recibido el activo y el importe esperados.
Si utilizas un servicio de historial de transferencias, conserva el alcance de la consulta y todas las páginas. El punto de acceso de transferencias de tokens de Etherscan ofrece filtros por cadena, dirección, contrato, intervalo de bloques y paginación. La primera página no es el registro completo de un día. Los datos de un explorador son pruebas complementarias, no un sustituto de la asignación a pedidos.
Realiza el cierre diario en un orden fijo
1. Define la hora de corte y recopila los registros
Elige una zona horaria empresarial y un intervalo de información exacto, con el inicio incluido y el final excluido. Registra tanto ese intervalo como las marcas de tiempo UTC utilizadas en las consultas. Indica si el informe agrupa las transferencias según la hora del bloque, la hora de confirmación del proveedor u otro criterio documentado.
Recopila los pedidos y registros de pago del período, además de las partidas pendientes de períodos anteriores. Obtén las transferencias de cada dirección de recepción de la empresa y cada red admitida mediante los registros disponibles o datos verificados de la cadena de bloques. No des por hecho que un panel o una API dispone de una función concreta de exportación sin haberlo comprobado.
Conserva la fecha y hora de consulta y el intervalo de bloques. Una transferencia observada cerca de la hora de corte puede cumplir tu política de confirmaciones más tarde; mantenla pendiente en lugar de modificar sin explicación las pruebas del día anterior.
2. Normaliza sin perder precisión
Mantén separadas las cantidades de activos y los valores facturados en moneda local. Guarda los importes de tokens en unidades mínimas exactas o en decimales exactos con una precisión verificada. No sumes USDC de distintas redes en un único saldo sin explicar su composición, ni mezcles USDT y USDC solo porque ambos buscan mantener un valor equivalente al dólar.
Si tu contabilidad necesita un valor en moneda local, registra la fuente de valoración, la fecha y hora y el método exigidos por tu política contable. El símbolo de una stablecoin no es una instrucción para contabilizar cada unidad recibida a exactamente un dólar estadounidense. Consulta a tu contador cómo tratar las comisiones y las variaciones de valor en tu jurisdicción.
3. Vincula y asigna una sola vez
Empieza por referencias fiables del pedido y del proveedor. Verifica el activo, la red, el destinatario, el importe y las pruebas de confirmación antes de asignar un cobro. Si varios pedidos solicitan el mismo importe, el importe y la hora por sí solos no demuestran la identidad del cliente.
Garantiza que cada registro de transferencia sea único y que las asignaciones no superen su importe disponible. Varias asignaciones aprobadas pueden compartir un cobro solo si tu proceso empresarial lo permite y se controla la suma. Recibir dos veces la misma notificación no debe generar un segundo cobro ni liberar el pedido dos veces.
4. Separa las incidencias de los totales de cierre
Mantén visibles los cobros sin asignar, los pedidos impagados y las confirmaciones pendientes. Asigna a cada diferencia un responsable, un motivo y una próxima acción. Utiliza la guía para pagos insuficientes y excesivos para resolver discrepancias de importe en lugar de improvisar otra solicitud por el pago completo.
Deriva las discrepancias de activo o cadena a la guía de pagos en la red equivocada. Una incidencia no queda resuelta solo porque alguien cambie su color en la hoja de cálculo.
5. Concilia los movimientos y aprueba el cierre
Para cada activo en cada red, concilia el saldo inicial y el final mediante entradas y salidas verificadas. Clasifica por separado los cobros de ventas, los reembolsos, las transferencias internas y los demás movimientos. Registra las comisiones de red en el activo realmente gastado; no descuentes sin indicarlo una comisión de gas en moneda nativa del cobro en stablecoins.
Utiliza esta conciliación de saldos como comprobación de integridad, no como cálculo de ingresos. Que los saldos cuadren no demuestra que todos los pedidos estén asignados correctamente, y el reconocimiento de ingresos puede seguir otras normas contables.
Ejemplo de cierre sin datos de clientes inventados
Este ejemplo ilustrativo se refiere a un único activo USDC en una sola red. Todos los movimientos cumplen los criterios de corte y la política de confirmaciones elegidos.
| Movimiento | USDC |
|---|---|
| Saldo inicial | 400 |
| Cobros de clientes verificados | +250 |
| Transferencia desde otra billetera de la empresa | +100 |
| Reembolso al cliente aprobado | -20 |
| Transferencia a otra billetera de la empresa | -150 |
| Saldo final | 580 |
El saldo aumentó en 180 USDC, pero los cobros de clientes fueron de 250 USDC. Ninguna de las dos cifras equivale automáticamente a ingresos reconocidos. Las transferencias internas modifican el saldo de esta billetera sin generar ventas; el reembolso permanece vinculado a su pedido original. Las comisiones de red en moneda nativa deben figurar en la conciliación separada de ese activo.
Un revisor también debe comprobar que cada parte de los 250 USDC tenga una asignación a un pedido o una clasificación explícita como pendiente de resolver. Que el saldo inicial y el final cuadren no permite detectar un cobro asignado al cliente equivocado.
Dónde encaja Yolfi en la cadena de registros
La página de enlaces de pago de Yolfi describe cómo crear enlaces de pago, seguir los pagos y recibir fondos directamente en tu billetera. Esto aporta al comercio el contexto de la solicitud de pago junto a los cobros de la billetera; no elimina la necesidad de conectar esos registros con los pedidos.
Antes de aceptar un pago real, comprueba el activo, la red y la dirección de recepción que ofrece tu configuración efectiva. Conserva la referencia de pago disponible y tu propia referencia de pedido. Verifica qué registros expone tu integración actual antes de diseñar un proceso de conciliación automatizado. No deduzcas formatos de exportación, integraciones contables ni reglas de vinculación a partir de una página pública de marketing.
Para los negocios de servicios que cobran anticipos o pagos por hitos, la guía de enlaces de pago para profesionales independientes explica la parte comercial. Conserva ese alcance junto a las pruebas de pago para no confundir un anticipo con el pago íntegro de un proyecto.
Preguntas frecuentes
¿Puedo conciliar solo con los saldos de las billeteras?
No. Los saldos pueden ayudar a comprobar los movimientos, pero no explican a qué pedido corresponde un cobro, las transferencias internas, las obligaciones pendientes ni si un cobro representa ingresos.
¿Un hash de transacción siempre equivale a un pago?
No. Una transacción puede incluir varias transferencias. Conserva la red y el identificador de transferencia adecuado para esa cadena y asigna después el cobro correspondiente al pedido correcto.
¿Qué ocurre si un pago se confirma después de la hora de corte diaria?
Conserva la observación original y tramita la partida según tu proceso documentado de paso de pendiente a confirmado. Aplica un criterio de información coherente y conserva un historial de correcciones en lugar de reescribir en silencio un período cerrado.
¿La conciliación requiere un programa de contabilidad automatizado?
No necesariamente. Una hoja de cálculo con controles puede funcionar con poco volumen si conserva importes exactos, referencias únicas, pruebas e historial de revisión. Pasa a una base de datos o a una integración contable cuando el volumen o el riesgo de error hagan poco fiables los controles manuales.
Cierra con pruebas, no con un cero forzado
Un cierre diario útil termina con cobros vinculados, movimientos de billetera clasificados y una breve lista de incidencias con responsables. No exige ocultar partidas sin resolver. Empieza con instrucciones claras para los enlaces de pago, conserva la relación con el pedido y deja que las pruebas verificadas de las transferencias determinen qué puede cerrarse.
