Nordlet

← Documentación / Guías

Importaciones de bancos y pagos

Extractos camt.053, CSV de Stripe, conciliación de liquidaciones de PSP y fuentes JSON personalizadas.

Todas las importaciones llegan como transacciones bancarias en una cuenta bancaria (bank/accounts/create). Las transacciones llevan un externalId; volver a importar el mismo archivo es seguro, ya que las filas cuyas combinaciones (bankAccountId, externalId) ya existan se omiten y se comunican en el contador skipped. Las transacciones importadas comienzan con el estado new y solo se contabilizan en el libro mayor cuando se concilian (bank/transactions/match, utilizando bank/transactions/suggest-matches para los candidatos).

La aplicación web expone las mismas importaciones en Banco → Importar archivo (carga de archivos, selector de plantillas).

Una conciliación incorrecta se deshace con bank/transactions/unmatch (Desconciliar en Banco → Transacciones). Los asientos contabilizados nunca se editan ni se eliminan: un pago conciliado con una factura, o una línea que una plantilla de importación haya contabilizado en una cuenta, genera un asiento contable de reversión con cada asiento en el lado opuesto, con fecha date (por defecto: hoy, y nunca anterior al original). El importe pagado y el estado de pago de la factura retroceden por el valor de esa línea bancaria. Una línea vinculada a una liquidación de un proveedor de pagos solo se desvincula, ya que el asiento de la liquidación pertenece al lote. La línea regresa al estado new y se puede volver a conciliar. La fecha de reversión debe recaer en un período contable abierto.

Plantillas de importación

Una plantilla de importación nombra una fuente de datos, enumera los campos que proporciona la fuente y asigna los campos que transportan dinero a las cuentas del libro mayor. Las plantillas se gestionan en Banco → Plantillas de importación y a través de bank/import-templates/create|update|delete|get|list.

POST /v1/v1/bank/import-templates/create
{
  "name": "Stripe payments export",
  "type": "stripe",
  "fields": [
    { "name": "id" },
    { "name": "Created date (UTC)" },
    { "name": "Amount" },
    { "name": "Fee", "accountCode": "6800" },
    { "name": "Amount Refunded" }
  ],
  "metaFields": ["order_id"]
}
  • type es uno de los siguientes valores: stripe, iso20022, bank_connection o revolut.
  • Cada campo tiene un name y un accountCode opcional. Solo los campos que transportan dinero admiten una cuenta: Amount, Fee y Amount Refunded de Stripe; Ntry/Amt de camt.053; transaction_amount.amount del feed bancario. La cuenta debe existir en el plan contable (créala con ledger/accounts/create).
  • El parámetro fields se puede omitir; en ese caso, toma por defecto la lista estándar de campos de ese tipo: los nombres de columna del archivo de Pagos → Exportar de Stripe (sin las 19 columnas Card ..., que el formulario también deja desmarcadas por defecto), los elementos de camt.053 que contiene todo extracto (Stmt/Id, Stmt/Acct/Id/IBAN, Stmt/Bal/..., Ntry/Amt, Ntry/CdtDbtInd, Ntry/Sts, Ntry/BookgDt), o los atributos que devuelve un feed bancario PSD2 por transacción. Agrega o elimina entradas para que coincidan con tu archivo: el importador también lee los elementos opcionales de camt.053 Ntry/ValDt, Ntry/NtryRef, Ntry/AcctSvcrRef, Ntry/AddtlNtryInf, TxDtls/Refs/EndToEndId, TxDtls/Refs/TxId, TxDtls/RltdPties/Dbtr/Nm, TxDtls/RltdPties/DbtrAcct/Id/IBAN, TxDtls/RltdPties/Cdtr/Nm, TxDtls/RltdPties/CdtrAcct/Id/IBAN, TxDtls/RmtInf/Ustrd y TxDtls/AddtlTxInf.
  • Un campo Customer Email de Stripe puede incluir "createPartner": true. La importación crea entonces un cliente (tercero de tipo persona, marcado como cliente) para cada correo electrónico del archivo que no tenga un tercero existente, utilizando Customer Description como nombre (el correo electrónico si está vacío) y las columnas Card Address ... como dirección si el archivo las contiene. Los terceros existentes se identifican por correo electrónico, sin distinguir entre mayúsculas y minúsculas. La respuesta informa el recuento en customersCreated.
  • metaFields (solo para Stripe) enumera las claves de metadatos que transportan tus cargos. Stripe exporta cada clave como una columna <key> (metadata); la lista es de formato libre y puede ser extensa.
  • invoiceItemId (solo para Stripe, opcional) es un artículo del catálogo. Cuando se define, cada línea de factura y nota de crédito que crea la importación hace referencia a ese artículo (su contabilización y, si invoiceVatRatePercent está vacío, su tipo de IVA); el texto de la línea sigue proviniendo del cargo.
  • companyMetaField (solo para Stripe) designa una de esas claves como el indicador de empresa. Cuando un cargo lleva true, 1, yes, company, business o b2b en esa columna, el cliente creado para él es un tercero de tipo empresa en lugar de persona.
  • invoiceMetaField (solo para Stripe) designa una de esas claves, por ejemplo un número de pedido, e invoiceVatRatePercent define el tipo de IVA para las facturas creadas a partir de ella. Al importar, cada fila de cargo y reembolso se agrupa por el valor de esa clave:
    • un valor que coincide con una factura de venta existente (un pedido de venta cuyo externalRef sea ese valor (ecommerce/orders/create, cualquier canal) o una factura cuyo fullNumber sea ese valor) vincula el grupo a dicha factura;
    • un valor sin factura crea una: tercero a partir de Customer Email (creado si falta, al igual que para createPartner), una línea por cargo (Checkout Line Item Summary o Description como texto, el importe del cargo como precio con IVA incluido al invoiceVatRatePercent), fecha de emisión = la fecha del primer cargo, tratamiento del IVA a partir de la empresa y el país de la tarjeta. La factura se emite y se contabiliza de inmediato, y se registra un pedido de venta con el canal stripe y ese valor como externalRef para que las importaciones posteriores realicen vinculaciones en lugar de creaciones;
    • cada cargo del grupo se concilia con la factura como un pago (contabilizando el cobro); cada reembolso crea una nota de crédito emitida contra la factura por el importe reembolsado y concilia el reembolso con ella. Los recuentos se devuelven como invoicesCreated, invoicesLinked, creditNotesCreated y paymentsMatched; los grupos que no se pudieron procesar (sin correo electrónico de cliente, monedas mixtas, una factura vinculada que aún es un borrador o que ya está totalmente pagada) se enumeran en warnings y se dejan como transacciones bancarias en estado new. No asigne también Amount a una cuenta del libro mayor en la misma plantilla: un cargo conciliado con una factura no se contabiliza una segunda vez, pero uno no conciliado sí lo haría.
  • Los nombres de las plantillas son únicos por empresa.
  • Las plantillas de camt.053 y de conexión bancaria tienen las mismas opciones, leídas del extracto en lugar de las columnas de Stripe:
    • Crear terceros faltantes: createPartner en la fila del nombre del deudor (TxDtls/RltdPties/Dbtr/Nm, feed debtor.name) crea un cliente para cada pagador desconocido de dinero entrante; en la fila del nombre del acreedor (TxDtls/RltdPties/Cdtr/Nm, feed creditor.name), un proveedor para cada beneficiario desconocido de dinero saliente. Los terceros se reconocen por IBAN (almacenado en partner_bank_accounts), y luego por nombre exacto; un nuevo tercero es una empresa si el nombre contiene una forma jurídica (UAB, MB, SIA, GmbH, Ltd, ...), de lo contrario es una persona. El recuento se devuelve como customersCreated (importación de archivos) o partnersCreated (sincronización de feeds).
    • Vincular facturas por referencia: invoiceMetaField configurado en una fila de concepto o referencia (TxDtls/RmtInf/Ustrd, TxDtls/RmtInf/Strd/CdtrRefInf/Ref, TxDtls/Refs/EndToEndId; feed remittance_information, reference_number) concilia cada nueva línea bancaria cuya referencia, concepto o descripción contenga el número de una factura de venta emitida abierta (dinero entrante) o una factura de compra registrada (dinero saliente), y contabiliza el pago. Cuando el IBAN del pagador está guardado en un tercero, o el nombre del pagador es igual al nombre o código de un tercero, la factura debe pertenecer a ese tercero. Un pago de un pagador desconocido se vincula únicamente cuando coincide con el saldo pendiente de la factura y el número de factura incluye su prefijo de serie, de modo que un número aislado, como un importe, nunca se toma como referencia. Un pago superior al saldo pendiente nunca se vincula. Las líneas que no superan estas comprobaciones permanecen en estado new para su conciliación manual y se enumeran en las advertencias (warnings). Con advanceInvoices: true, un pago entrante no conciliado de un tercero conocido crea una factura de anticipo emitida (tipo advance) por el importe al tipo de invoiceVatRatePercent o al tipo de invoiceItemId y concilia el pago con ella; el tercero debe ser conocido, por lo que debe marcar también la fila del deudor.
    • Reglas de contabilización por código de transacción: además de Ntry/Amt / transaction_amount.amount, la lista de campos incluye filas de reglas Ntry/BkTxCd=CHRG, =INTR, =TAXE, Ntry/CdtDbtInd=DBIT, =CRDT (feed: bank_transaction_code=..., credit_debit_indicator=...). Una línea se contabiliza en la cuenta de la primera regla con la que coincida: primero su familia de código de transacción bancaria, luego su dirección y, por último, la fila de importe simple. Las filas de reglas no se contrastan con el archivo.
    • Tercero de comisiones bancarias: createPartner en la fila de reglas ...=CHRG crea un proveedor con el nombre del banco (extracto Stmt/Acct/Svcr/FinInstnId/Nm, o el banco de la conexión, o el nombre de la cuenta bancaria del libro mayor) y registra cada comisión con ese tercero.
    • Las plantillas de conexión bancaria se seleccionan por cuenta de feed con bank/feeds/accounts/configure (Banco → Conexiones en la aplicación), que también configura syncSchedule (manual, daily, weekly, monthly): la API sincroniza las cuentas con un programa de forma autónoma una vez que ha transcurrido su período. Las plantillas se aplican en cada bank/feeds/sync; la respuesta de sincronización también informa entonces sobre posted, partnersCreated, invoicesLinked, invoicesCreated, paymentsMatched y warnings.

Pase templateId a bank/statements/import en lugar de format: el tipo de la plantilla selecciona el analizador sintáctico (parser) y el archivo debe contener todos los campos enumerados en la plantilla; un archivo al que le falte cualquiera de ellos es rechazado con el código HTTP 422 y los nombres de la columna o elemento faltante. No es obligatorio que los campos de metadatos estén presentes. Las plantillas de conexión bancaria describen un feed PSD2 en directo y no se pueden utilizar para la importación de archivos.

Una plantilla ISO 20022 también lee archivos MT940: un archivo que comienza con {1: o :20: (o se envía con "format": "mt940") se analiza como MT940 y las reglas de coincidencia de referencias y contabilización de la plantilla se aplican a sus líneas. La comprobación de elementos se omite para el formato MT940, y las reglas Ntry/BkTxCd=... nunca se aplican a las líneas MT940 porque este formato no incluye ningún código de transacción bancaria ISO 20022; utilice en su lugar las reglas Ntry/CdtDbtInd=....

Una cuenta bancaria mantiene una sola moneda. Se rechaza con HTTP 422 un extracto en otra moneda (en un archivo camt.053 con extractos en varias monedas para el mismo IBAN, solo se importa el extracto que coincide con la moneda de la cuenta), y lo mismo ocurre con una línea enviada a bank/transactions/import con una currency distinta a la de la cuenta.

Cada movimiento producido a partir de un campo que tiene un accountCode se contabiliza en el momento de la importación como un único asiento contable: el dinero entrante debita la cuenta del libro mayor de la cuenta bancaria y acredita la cuenta asignada; el dinero saliente debita la cuenta asignada y acredita la cuenta del libro mayor de la cuenta bancaria. Los importes se convierten a la moneda base en la fecha del movimiento. La transacción bancaria se concilia (matched) entonces con ese asiento contable (matchedDocumentType = journal_transaction) y deja de ofrecerse para la conciliación de facturas. La respuesta informa el recuento en posted. Los movimientos de campos no asignados se quedan en estado new y se concilian con las facturas como antes; por ejemplo, asigne Fee a la cuenta de gastos de comisiones del PSP y deje Amount sin asignar para que los cargos sigan conciliándose con las facturas de venta.

POST /v1/bank/statements/import
{
  "bankAccountId": "...",
  "templateId": "...",
  "content": "id,Created date (UTC),Amount,..."
}

ISO 20022 camt.053 (XML de banca abierta)

Los bancos lituanos (Swedbank, SEB, Luminor, Šiaulių bankas, ...) permiten descargar los extractos de cuenta en formato XML camt.053 ISO 20022 desde su banca por Internet, normalmente en la sección de exportación/descarga de extractos, con el formato "ISO XML" o "camt.053". Las APIs de información de cuentas PSD2 devuelven el mismo formato.

POST /v1/bank/statements/import
{
  "bankAccountId": "...",
  "format": "camt053",
  "content": "<?xml version=\"1.0\"...>..."
}
  • Un archivo puede contener varios extractos; el IBAN de cada extracto debe coincidir con el IBAN de la cuenta bancaria (los extractos sin IBAN, o las cuentas sin él, se aceptan tal cual).
  • Las referencias de los movimientos (AcctSvcrRef/NtryRef, recurriendo a un hash del contenido si no existen) se convierten en el externalId.
  • La respuesta devuelve metadatos por extracto: ID del extracto, período, saldos iniciales y finales, recuento de transacciones.
  • El nombre de la contraparte, el IBAN y el concepto del pago se extraen por movimiento para su conciliación.

Los pagos en dirección contraria se exportan como pain.001 mediante bank/payments/export.

CSV de Revolut Business

Descargue el extracto de transacciones de una cuenta de Revolut Business en formato CSV e impórtelo con la plantilla integrada Revolut Business (templateId: "builtin-revolut"). Todas las empresas disponen de esta plantilla sin necesidad de crearla: bank/import-templates/list-builtin la enumera, bank/import-templates/get la devuelve, y bank/import-templates/update y bank/import-templates/delete la rechazan con un error HTTP 400. En la aplicación, aparece en primer lugar en Banco → Plantillas de importación; al abrirla se muestran su configuración y, al guardarla, se crea una plantilla de empresa propia que se puede modificar.

POST /v1/bank/statements/import
{
  "bankAccountId": "...",
  "templateId": "builtin-revolut",
  "content": "Date started (UTC),Date completed (UTC),ID,Type,State,..."
}
  • Solo se importan las filas con State = COMPLETED. Las demás filas (por ejemplo, PENDING) se omiten y se contabilizan en warnings; se importarán en una importación posterior de un archivo en el que ya aparezcan como completadas.
  • Cada fila se convierte en una transacción bancaria con la fecha de Date completed (UTC), el importe de Total amount, la moneda de Payment currency, el campo ID como externalId y Description como descripción.
  • La contraparte del dinero saliente es Beneficiary name y Beneficiary IBAN; para un pago con tarjeta sin beneficiario, el comercio indicado en Description. La contraparte del dinero entrante es Sender name y Sender account.
  • Las filas se agrupan por cuenta y moneda. International account number debe coincidir con el IBAN de la cuenta bancaria, y solo se importan las filas que estén en la moneda de la cuenta bancaria.
  • Para cada fila, el importador comprueba que el saldo de la fila anterior más Total amount sea igual a Balance, y enumera en warnings todas aquellas filas en las que no coincida.
  • El archivo debe contener las columnas Date completed (UTC), ID, Type, State, Description, Payment currency, Total amount, Reference, Sender name y Beneficiary name.

En cada importación, la plantilla integrada realiza lo siguiente:

  • crea un cliente para cada emisor desconocido de dinero entrante, y un proveedor para cada beneficiario desconocido o comercio de tarjeta de dinero saliente, tal como se describe en la sección Crear terceros faltantes anterior;

  • concilia cada fila cuyo campo Reference o Description contenga el número de una factura de venta o compra abierta, y contabiliza el pago aplicando las comprobaciones de la sección Vincular facturas por referencia anterior;

  • contabiliza las filas que ninguna factura haya conciliado según su campo Type, asignándolas a la cuenta de una regla de contabilización:

    Type Regla de contabilización Cuenta por defecto Plan rumano Contabilización
    FEE bank.fees 6800 627 debita la cuenta de la regla y acredita la cuenta del libro mayor de la cuenta bancaria; tercero: un proveedor nombrado con el nombre de la cuenta bancaria
    CARD_PAYMENT bank.cardPayments 6209 628 debita la cuenta de la regla y acredita la cuenta del libro mayor de la cuenta bancaria, sin IVA
    TOPUP bank.topUps 3010 1012 debita la cuenta del libro mayor de la cuenta bancaria y acredita la cuenta de la regla

    Las filas de otros tipos, como TRANSFER, permanecen en estado new para su conciliación.

Modifique las cuentas con ledger/posting-rules/update; la plantilla integrada utilizará las nuevas cuentas a partir de la siguiente importación. Una regla de contabilización no se puede desactivar: para importar pagos con tarjeta o recargas sin contabilizarlos, cree una plantilla de empresa de tipo revolut sin las filas Type=CARD_PAYMENT o Type=TOPUP e importe con ella. Un pago con tarjeta contabilizado de esta manera no se concilia con la factura del proveedor cuando dicha factura se registre más tarde; contabilice uno de los dos, pero nunca ambos.

Una plantilla de empresa de tipo revolut utiliza las mismas columnas y puede contabilizar filas por tipo utilizando las reglas Type=FEE, Type=CARD_PAYMENT, Type=TRANSFER y Type=TOPUP. Importar con "format": "revolut-csv" y sin ninguna plantilla importa las filas sin aplicar ninguno de estos pasos.

CSV de Stripe

Realice la exportación desde el panel de control de Stripe (cualquiera de los dos informes es válido):

  • Informes → Saldo → Cambio de saldo detallado por actividad (recomendado): columnas balance_transaction_id, created_utc, currency, gross, fee, net, reporting_category, description.
  • Pagos → Exportar: columnas id, Created (UTC), Amount, Fee, Currency, Description, Customer Description.
POST /v1/bank/statements/import
{
  "bankAccountId": "...",
  "format": "stripe-csv",
  "content": "balance_transaction_id,created_utc,currency,gross,fee,net,..."
}

Cree una cuenta bancaria dedicada para Stripe (por ejemplo, con el nombre "Stripe", cuenta contable 2710 o su propia subcuenta); el saldo de Stripe se comporta como una cuenta bancaria: los cargos fluyen hacia ella, se deducen las comisiones y los desembolsos (payouts) transfieren el saldo a su cuenta bancaria real.

Comportamiento de la importación:

  • Cada transacción de saldo se convierte en una transacción bancaria por el importe bruto (externalId = ID de la transacción de saldo).
  • Una comisión (fee) distinta de cero se convierte en una segunda transacción con signo opuesto (externalId = <id>:fee, contraparte "Stripe"), de modo que las comisiones se pueden conciliar o contabilizar como gastos de forma independiente de los ingresos. Las comisiones devueltas en los reembolsos se registran como importes positivos.
  • Las filas de desembolso (payout) se importan como transacciones negativas individuales; concíliese con la transacción de entrada correspondiente en el extracto de su cuenta bancaria real.
  • Las filas con importe cero se omiten; la fecha se toma de created_utc (UTC).
  • Las filas de exportación de pagos que no supusieron movimiento de dinero se omiten: Captured = false (autorizaciones o capturas diferidas) y Status con valor Failed/Canceled.
  • Un importe reembolsado (Amount Refunded) distinto de cero se convierte en una tercera transacción negativa (externalId = <id>:refund) con fecha Refunded date (UTC), asegurando que no se pierdan los reembolsos parciales o totales integrados en las filas de pago.

Conciliación de liquidaciones de PSP (informes de desembolsos de Stripe)

Para desglosar un pago global (lump-sum) en sus pedidos subyacentes, reembolsos, comisiones y devoluciones de cargos (chargebacks), utilice los endpoints de liquidación en lugar de la importación de extractos estándar. Se aceptan dos tipos de exportaciones de Stripe (detectadas automáticamente):

  • Informes → Desembolsos → Conciliación de desembolsos, detallada (tipos de informe payout_reconciliation.itemized.* o payout_reconciliation.by_id.itemized.*): exacta, una fila por transacción de saldo; es la opción preferida en cuentas reales.
  • Pagos → Exportar (pagos unificados): la exportación a nivel de cargo; funciona en modo de prueba/sandbox donde la conciliación de desembolsos no está disponible. Los cargos capturados se agrupan por el ID de desembolso en la columna Transfer; las filas no capturadas o fallidas se omiten (skippedNotSettled); un Amount Refunded distinto de cero se convierte en una línea de reembolso sintética dentro del lote de desembolso del cargo (una aproximación, ya que el reembolso podría haberse liquidado realmente en un desembolso posterior). Las referencias de conciliación provienen del ID de cargo, PaymentIntent ID, Invoice Number, Client Reference ID y de cada columna ... (metadata) (por ejemplo, un número de pedido en los metadatos).

Un solo archivo CSV puede abarcar múltiples desembolsos. Stripe descarga el informe detallado un archivo por sección (..._charge_..., ..._refund_..., ..._fee_...); impórtelos todos. Las filas correspondientes a un desembolso ya importado se fusionan en el lote existente (se informa en el contador updated) siempre y cuando este no se haya contabilizado todavía, y los totales del lote se recalculan.

POST /v1/bank/settlements/import
{
  "bankAccountId": "...",
  "provider": "stripe",
  "content": "balance_transaction_id,created_utc,...,reporting_category,...,automatic_payout_id,..."
}

Comportamiento de la importación:

  • Las filas se agrupan por automatic_payout_id en lotes de liquidación (un lote por desembolso), con totales brutos, de comisiones y netos (la suma del campo net de las filas es el importe que llega a su banco). La reimportación de un desembolso se omite (contador skipped). Las filas que aún no están asignadas a un desembolso y las filas de tipo payout se omiten y se contabilizan por separado.
  • Cada fila de cargo, reembolso o disputa se concilia automáticamente con una factura de venta utilizando, en el siguiente orden: el externalRef de un pedido de comercio electrónico (cualquier valor procedente de order_id, payment_intent_id, source_id, charge_id o cualquier columna *_metadata[...]), un fullNumber de factura que aparezca en dichas columnas y, para los reembolsos y devoluciones de cargos, el charge_id de un cargo previamente conciliado (del mismo archivo o de importaciones anteriores).
  • Revise los datos con bank/settlements/list / bank/settlements/get; corrija los elementos pendientes con bank/settlements/match { lineId, invoiceId } (o invoiceId: null para desconciliar).

POST /v1/bank/settlements/post { id, date?, commissionPercent? } contabiliza el lote completo como un único asiento contable equilibrado y liquida las facturas conciliadas (webhooks paidAmount/paymentStatus, sale_invoice.paid):

  • Debita la cuenta del libro mayor de la cuenta bancaria por el neto del desembolso; debita las comisiones del PSP (settlements.fees, por defecto 6800) por las comisiones retenidas y las filas de comisiones.
  • Acredita las cuentas por cobrar por cada cargo conciliado; los reembolsos y las devoluciones de cargos invierten esta operación. La aplicación está limitada al importe pendiente de cada factura; cualquier excedente se destina a la cuenta transitoria (suspense) junto con una advertencia.
  • Cargos no conciliados: si se define commissionPercent, se dividen entre los ingresos por comisiones (settlements.commissionRevenue, por defecto 5001) y una cuenta a pagar a vendedores (settlements.sellerPayable, por defecto 4499), reflejando el flujo de marketplace donde el dinero recaudado pertenece mayoritariamente a los vendedores. Si no se define, se aparcan en settlements.suspense (por defecto 4440, anticipos recibidos).
  • Las filas de platform_earning (comisiones de aplicación de Stripe Connect) se contabilizan en los ingresos por comisiones; las filas de transfer (desembolsos a vendedores conectados) reducen la cuenta a pagar a vendedores.
  • Las cuatro cuentas se pueden sobrescribir por empresa mediante las reglas de contabilización (ledger/posting-rules).
  • Una línea cuyo cargo, comisión o reembolso ya se hubiera importado en otra cuenta bancaria a partir de la exportación de pagos de Stripe (bank/statements/import) no se registra en las cuentas de comisiones, de clientes ni transitoria. En su lugar, su importe neto (net) se acredita en la cuenta del libro mayor de esa cuenta bancaria, de modo que la cuenta bancaria de Stripe se va depurando desembolso a desembolso. summary.clearedAmount representa el total movido de este modo; una línea cuyo importe difiere del que contiene esa cuenta se indica en warnings. Si no queda nada por registrar, el lote se contabiliza con journalTransactionId nulo.

bank/settlements/list y /get devuelven, por cada lote, los valores clearedNet, clearingDifference (líneas de desembolso menos los importes que la otra cuenta bancaria retiene para ellas; valor cero cuando coinciden) y clearingOpenCount (líneas con diferencia o con un movimiento sin contabilizar); /get devuelve los mismos datos por línea como clearingBankAccountId, clearingBooked, clearingDifference y clearingUnposted. Las líneas de reembolso de un mismo cargo se comparan conjuntamente, dado que la exportación de pagos solo conserva el total reembolsado. Una exportación de pagos de Stripe importada después de que su desembolso haya sido contabilizado omite los movimientos de dicho desembolso y los menciona en warnings.

El IVA de la comisión en sí se factura por separado (emitiendo una factura de comisión al vendedor); la división únicamente asigna el efectivo recaudado.

Desembolsos en otra moneda

El libro mayor se redacta siempre en la moneda base de la empresa, pero un desembolso en una moneda diferente se contabiliza de forma automática sin necesidad de intervención manual:

  • El lote realiza la conversión al tipo de cambio correspondiente a la fecha de contabilización (date, recurriendo a la fecha del desembolso y, en su defecto, a la fecha de hoy). El tipo de cambio utilizado es el propio de la empresa para esa moneda (reference/exchange-rates/set) siempre que sea al menos tan reciente como el oficial; de lo contrario, se toma el último tipo de cambio oficial en esa fecha o en la inmediatamente anterior. Si no existe ningún tipo de cambio en esa fecha o antes, la llamada falla con el código 422 y menciona reference/exchange-rates/sync.
  • Todas las cuentas se convierten utilizando el tipo de cambio del lote excepto las cuentas por cobrar, las cuales se cancelan al tipo de cambio (fxRate) al que se emitió cada factura. La diferencia resultante entre ambos tipos de cambio se contabiliza en bank.fxGain (por defecto 5803) o bank.fxLoss (por defecto 6803) como una diferencia de cambio realizada, garantizando que el asiento contable permanezca equilibrado.
  • El objeto summary de la respuesta devuelve el tipo de cambio (fxRate) utilizado y la diferencia de cambio resultante (exchangeDifference), y el lote conserva el tipo de cambio al que se contabilizó. Una factura conciliada cuya propia moneda difiere de la del lote no se liquida: su importe se transfiere a la cuenta transitoria con una advertencia.
  • Se mantiene un límite de importación: un único desembolso cuyas filas mezclen varias monedas se rechaza con el código 422, al igual que una reimportación cuya moneda difiera de la del lote ya almacenado para dicho desembolso.

Fuentes manuales o personalizadas

Cualquier otro elemento se puede enviar como JSON plano:

POST /v1/bank/transactions/import
{
  "bankAccountId": "...",
  "transactions": [
    { "date": "2026-07-01", "amount": "-25.00", "currency": "EUR",
      "counterpartyName": "...", "description": "...", "externalId": "unique-ref-1" }
  ]
}

Proporcione un externalId estable por transacción para garantizar que las reimportaciones sean idempotentes.