Cinco versiones de una misma transacción: por qué su pago en USDT puede quedarse en pausa
Un pago legal en USDT no es un solo txid, sino cinco versiones de la misma operación que deben coincidir. En la práctica, la operación se frustra no tanto por el activo "sucio", sino porque el contrato, el banco, el cumplimiento normativo, la contabilidad y la función fiscal describen la misma transferencia de manera diferente. Este es un problema fundamental que requiere un enfoque sistémico.
Tomemos un ejemplo transversal: una empresa rusa importa equipos por $100,000 y el proveedor está dispuesto a aceptar 100,000 USDT. Para el director general, es un solo pago, pero para cada función interna es un evento separado con su propio objeto, fecha, valor y conjunto de pruebas.
Versión 1. Contrato: el momento del pago debe existir no solo en la cadena de bloques
El hash de la transacción solo confirma que los tokens se movieron entre direcciones. No responde a cuatro preguntas legales: a quién pertenecía la dirección del destinatario, en virtud de qué obligación se realizó la transferencia, qué monto de deuda se saldó y qué sucede si los tokens se congelan, se devuelven o no están disponibles. El registro de "pago en USDT" en el contrato no es suficiente. El modelo mínimo debe vincular el precio de la mercancía, el activo de liquidación y la prueba de ejecución, así como fijar la moneda del precio, el token específico, la red, el tipo de dirección, la fuente de cotización, las comisiones y el momento del cumplimiento de la obligación. Los datos de pago requieren especial atención: la dirección identificadora y la red de la cadena de bloques deben especificarse en el acuerdo, y ante un cambio, debe preverse un procedimiento de aprobación y la prohibición de sustitución mediante una sola carta.
Versión 2. Control de cambios y banco: el significado económico importa más que el hash
Desde 2024, el Banco Central de Rusia puede establecer un régimen legal experimental para la moneda digital en liquidaciones de comercio exterior, pero esto no es un permiso general para pagar desde cualquier billetera. Para el banco, la operación comienza con el contrato de comercio exterior, la base económica y el rastro monetario en rublos. El banco autorizado debe comprender por qué la empresa transfirió rublos a un intermediario, qué activo adquirió, en qué cantidad, a quién y bajo qué contrato lo transfirió. Si cada documento existe por separado y no contiene un identificador común, la operación se descompone en fragmentos no relacionados. La Instrucción del Banco Central N.º 181-I ya incluye códigos para liquidaciones con moneda digital (99080, 99081), pero el código no reemplaza el contenido económico.
Versión 3. AML/KYT: un contraparte confiable puede recibir un activo riesgoso
En el comercio exterior tradicional, se verifica la entidad legal, sus propietarios, el estado de sanciones y el propósito comercial. En el comercio exterior criptográfico, se agrega el análisis de direcciones y el historial de movimiento del activo: KYT. Un KYB de calidad no limpia el historial del token, y un bajo riesgo de dirección no confirma la realidad del proveedor. No se puede reducir KYT a un indicador de "color": los sistemas analíticos calculan el riesgo según su propia metodología, por lo que dos sistemas pueden dar resultados diferentes. La verificación debe realizarse en al menos tres puntos: al elegir la fuente de liquidez, antes de adquirir el activo y antes de transferirlo al destinatario, ya que el historial de la dirección puede cambiar. El riesgo especial de USDT está relacionado con el emisor: la dirección puede congelarse a nivel del propio token, por lo que "transacción confirmada" y "el destinatario dispone definitivamente del valor" no siempre son lo mismo.
Versión 4. Contabilidad: el activo debe verse antes de darlo de baja
Las normas contables rusas aún no ofrecen un modelo universal para todos los tipos de activos digitales. La contabilidad comienza con un juicio profesional: si el objeto cumple con las características de un activo, quién lo controla, con qué propósito se adquirió y cómo se valorará. Esta decisión se fija en la política contable antes de la operación, no después de la solicitud del auditor. Para la contabilidad, es importante el ciclo de vida completo: la empresa transfiere rublos al intermediario, obtiene el derecho al activo digital, lo controla directamente o a través de un depositario, asume comisiones y solo entonces transfiere el activo al proveedor. Si la contabilidad refleja solo el pago en rublos y el cierre de las cuentas por pagar, el activo digital "desaparece" en un corto período.
Versión 5. Impuestos: el pago al proveedor es una enajenación de propiedad
Desde el 1 de enero de 2025, la moneda digital se reconoce como propiedad a efectos del Código Tributario de la Federación de Rusia. Su venta no constituye un objeto de IVA, la base imponible se forma por separado según el artículo 282.3 del Código Tributario de la Federación de Rusia, no se realiza revalorización y los gastos requieren confirmación documental. La transferencia del activo al proveedor no puede contabilizarse automáticamente solo como pago del equipo. Si el objeto se califica como moneda digital, su enajenación genera un resultado fiscal independiente: se comparan el costo de adquisición y el monto del ingreso. El punto crítico es la fuente del precio y la fecha de valoración: el contrato puede fijar la tasa en el momento de la emisión de la factura, el intermediario en el momento de la compra, la cadena de bloques el tiempo de inclusión de la transacción y el registro fiscal la fecha de venta. Incluso con un USDT estable, diferentes puntos temporales dan diferentes montos en rublos.
Mi conclusión experta: una operación son cinco montos en rublos, y la discrepancia en sí misma no prueba un error. El problema surge cuando la empresa no puede construir un puente entre ellos. Recomiendo crear un registro consolidado que muestre por separado la tasa, la fuente, la fecha, el diferencial, las comisiones y el propósito de cada valoración. Entonces la diferencia se convierte en una parte explicable del modelo, y sin el registro parece un gasto no confirmado. La empresa debería realizar una "prueba en seco" de la operación con documentos antes del movimiento de dinero: crear un contrato hipotético, una solicitud, un conjunto de verificaciones y asientos contables, y luego encontrar las discrepancias. Esto es más barato que una operación bloqueada y más útil que una política general de decenas de páginas.