Stripe Connect Marketplace Accounting Workflow

La mayoría de los problemas contables en los marketplaces se deben a un solo error: tratar el pago (payout) de Stripe como si fuera un ingreso. El pago es el resultado neto de docenas de eventos económicos independientes, y registrarlo como una sola línea de ingresos borra la comisión de la plataforma, la deuda con el vendedor y cada una de las comisiones y disputas que contiene. Un flujo de trabajo correcto desglosa el pago antes de que cualquier importe toque el libro mayor.

Esta guía analiza cada categoría de transacción de saldo de Stripe Connect y la asigna a su cuenta contable correspondiente: cuentas por cobrar, ingresos por comisiones, pasivos con vendedores, gastos de tramitación y cuentas transitorias. Utiliza los endpoints documentados de importación y liquidación de Nordlet como mecanismo de registro, incluye un ejemplo práctico de liquidación y finaliza con una lista de comprobación de conciliación que puedes ejecutar antes de cada cierre.

Identifica el modelo de cargo de Connect antes de diseñar nada

Las normas contables no se pueden definir hasta que sepas qué modelo de cargo utiliza cada flujo de pago. El modelo determina qué saldo de Stripe soporta el cargo, quién asume las comisiones y dónde se reflejan inicialmente los reembolsos y las disputas.

Modelo de Connect	Cargo creado en	Asume las comisiones de Stripe	Los reembolsos y disputas reducen	Consecuencia contable
Cargos directos (Direct charges)	Cuenta conectada	Configurable por parte	El saldo de la cuenta conectada	La plataforma registra su comisión de gestión como ingresos; la actividad de pago del vendedor se gestiona principalmente en el libro mayor de la cuenta conectada.
Cargos de destino (Destination charges)	Plataforma, con transferencia inmediata a una cuenta conectada	Plataforma	Plataforma	La plataforma registra la cuenta por cobrar del cliente y la comisión de Stripe; la parte del vendedor es una cuenta por pagar, no un ingreso.
Cargos y transferencias separados (Separate charges and transfers)	Cargo en la plataforma y, a continuación, una o varias transferencias independientes	Plataforma	Plataforma	El cargo y las transferencias al vendedor son eventos separados; el pasivo con el vendedor se rastrea de forma independiente al cargo del cliente.

Las propias directrices de Stripe sobre cómo funcionan los cargos en una integración de Connect confirman que, en el caso de los cargos de destino y los cargos y transferencias separados, el saldo de la plataforma asume las comisiones de pago, los reembolsos y los contracargos (chargebacks). En los cargos directos, la cuenta conectada recibe el cargo y las comisiones se pueden debitar a cualquiera de las partes.

La regla práctica: no digas "el pago de Stripe es un ingreso del vendedor" o "el vendedor paga las comisiones" hasta que hayas anotado el modelo de cargo de cada flujo. Almacena ese modelo junto con cada transacción. Mezclar cargos directos y de destino bajo una misma regla de registro es la forma más rápida de reflejar erróneamente tanto los ingresos como los pasivos.

Esta guía asume cargos de destino o cargos y transferencias separados, ya que es donde el saldo de la plataforma concentra el peso contable y donde se construyen la mayoría de los libros mayores de los marketplaces.

Asigna el flujo de fondos antes de importar una sola fila

Antes de realizar cualquier importación, dibuja un mapa de transacciones de una sola página para cada flujo:

Customer payment
  -> Stripe charge / payment balance transaction
  -> Stripe fee
  -> platform application fee (commission)
  -> transfer to connected account
  -> refund or dispute (if applicable)
  -> Stripe payout
  -> bank receipt

Cada flecha es una transacción de saldo distinta con su propio ID, categoría, importe y fechas. Trata el saldo de Stripe como una cuenta de compensación bancaria (clearing account): los cargos entran, las comisiones y las transferencias salen, y el pago transfiere el remanente al banco real. La documentación sobre importaciones bancarias y de pagos de Nordlet recomienda exactamente este tratamiento para la actividad ordinaria en Stripe.

Elige el informe de Stripe adecuado

Para los lotes de liquidación con pagos automáticos, utiliza el informe de Conciliación de pagos, detallado (Payout reconciliation, itemized) de Stripe. Este informe ofrece una fila por transacción de saldo, agrupa las filas por reporting_category, asocia cada una a un automatic_payout_id y proporciona totales brutos, de comisiones y netos. La guía de selección de informes de Stripe documenta este informe y confirma que charge_id, connected_account_id y destination_payment_id son campos disponibles en Connect.

Cuando los pagos automáticos no estén habilitados (algunos acuerdos de pagos manuales), utiliza el informe de saldos (Balance report) en su lugar. No consideres que un resumen de pagos del Dashboard es prueba suficiente para realizar asientos. El resumen demuestra el total del lote, pero solo el informe detallado explica sus componentes.

Stripe recomienda realizar la clasificación por reporting_category en lugar de utilizar el campo anterior type, y cada fila incluye un ID source que se vincula al objeto subyacente. Ten en cuenta la restricción temporal: Stripe indica que los datos diarios de los informes suelen estar disponibles al mediodía del día siguiente, y los pagos instantáneos (instant payouts) no se pueden asignar de forma limpia a transacciones individuales, por lo que requieren una conciliación del historial de transacciones por separado.

Clasifica cada transacción de saldo por categoría

Utiliza reporting_category como el clasificador principal y, a continuación, inspecciona source_id, charge_id y las descripciones. La asignación relevante es la siguiente:

Actividad de Stripe	Categoría de informe (reporting_category)	Interpretación contable
Cargo al cliente, tarjeta o método de pago local	charge	Cuenta por cobrar financiada por el cliente o liquidación de venta
Reembolso	refund	Reversión del pago original del cliente
Comisión de tramitación retenida por Stripe	fee	Gasto por tramitación de pagos
Comisión de gestión de la plataforma	platform_earning	Ingresos por comisiones
Comisión de gestión reembolsada	platform_earning_refund	Reducción de los ingresos por comisiones
Transferencia a la cuenta conectada	transfer	Reducción del pasivo con el vendedor
Transferencia revertida	transfer_reversal	Recuperación de fondos de la cuenta conectada
Contracargo	dispute	Pérdida por contracargo; inspecciona el objeto de disputa de origen
Contracargo ganado o revertido	dispute_reversal	Recuperación de un contracargo registrado previamente
Pago al banco	payout	Movimiento bancario, no un ingreso
Pago revertido	payout_reversal	Retorno de fondos al saldo de Stripe
Reserva retenida	connect_reserved_funds / risk_reserved_funds	Fondos restringidos, no un gasto por defecto
Cobro de saldo negativo de larga duración	connect_collection_transfer	Evento de financiación o recuperación que requiere una política de riesgos

Una advertencia sobre la terminología: el campo de tipo de transacción de saldo anterior (type) utiliza etiquetas diferentes para los mismos eventos, entre ellos payment, application_fee y adjustment. La documentación sobre tipos de transacciones de saldo de Stripe enumera ambos vocabularios. No mezcles un valor de type en una regla basada en reporting_category y no inventes una categoría como dispute_loss que Stripe no exporte. Si una exportación incluye una etiqueta que no reconoces, conserva el valor exportado y verifícalo con el objeto de origen.

Registra la actividad normal del marketplace en el libro mayor

Para una plataforma con cargos de destino o cargos y transferencias separados, los asientos conceptuales son los siguientes:

Cargo al cliente (el dinero del cliente entra en el saldo de compensación de Stripe):

Dr Stripe clearing        Gross customer charge
    Cr Trade receivables   Gross customer charge

Comisión de tramitación de Stripe:

Dr Stripe fee expense      Stripe fee
    Cr Stripe clearing     Stripe fee

No compenses la comisión de Stripe contra los ingresos a menos que tu política contable lo requiera y admita explícitamente la presentación por importes netos.

Comisión de la plataforma (tus ingresos, deducidos de lo que de otro modo se le adeudaría al vendedor):

Dr Seller payable          Commission amount
    Cr Commission revenue   Commission amount

Transferencia al vendedor (liquidación de fondos adeudados, no un gasto):

Dr Seller payable          Transfer amount
    Cr Stripe clearing      Transfer amount

Una transferencia nunca es automáticamente un gasto. La parte del vendedor se convierte en un pasivo en el momento en que se produce el cargo, y la transferencia cancela dicho pasivo. Las reglas de registro de liquidaciones de Nordlet siguen este principio: las filas de platform_earning se registran en los ingresos por comisiones, mientras que las filas de transfer reducen el pasivo con el vendedor. Las claves de registro predeterminadas documentadas son settlements.commissionRevenue (por defecto 5001), settlements.sellerPayable (por defecto 4499), settlements.fees (por defecto 6800) y settlements.suspense (por defecto 4440), siendo cada una de ellas configurable por empresa a través de las reglas de registro en la API de Nordlet.

Gestiona los reembolsos vinculados a la venta original, no como elementos bancarios sueltos

Un reembolso está vinculado al cargo o factura original. Conceptualiza el asiento de la siguiente manera:

Dr Refunds / sales reversals    Refund amount
    Cr Trade receivables         Refund amount

El asiento real depende de si la venta ya se había reconocido, si se debe revertir el impuesto y si se ha reembolsado la comisión de gestión de la plataforma. Un único reembolso puede generar una reversión de cuentas por cobrar, una reversión de impuestos, el reembolso de una comisión de gestión, una reversión de transferencia o una reducción del pasivo con el vendedor, así como un impacto en las comisiones de Stripe que se debe verificar en lugar de dar por sentado.

La trampa temporal: un reembolso a menudo se liquida en un pago posterior al del cargo original. Es preferible utilizar el informe detallado de conciliación de pagos en lugar de un reembolso sintetizado a partir de una exportación a nivel de cargos. La documentación de Nordlet advierte explícitamente que un reembolso sintetizado a partir de una exportación de pagos (Payments) es solo una aproximación cuando el reembolso se liquida más tarde. El importador de liquidaciones puede procesar la fila del reembolso, relacionarla con la venta original y revertir la cuenta por cobrar cuando se publique el lote.

Trata las disputas por separado de los reembolsos

Una disputa es una reclamación del titular de la tarjeta o del banco emisor, y Stripe puede debitar tanto el importe disputado como una comisión por disputa antes de su resolución. En el caso de los cargos de destino y los cargos y transferencias separados, Stripe debuta el saldo de la plataforma por ambos conceptos, según sus directrices sobre reembolsos y disputas. La plataforma puede intentar la recuperación revirtiendo la transferencia al vendedor.

Pérdida de una disputa desde la perspectiva de la plataforma:

Dr Chargeback loss / receivable reopened   Disputed amount
Dr Dispute-fee expense                      Dispute fee
    Cr Stripe clearing                      Combined amount

Si el vendedor asume la pérdida y se confirma la recuperación:

Dr Seller payable / recovery account   Recoverable amount
    Cr Chargeback recovery              Recoverable amount

No registres la recuperación al vendedor simplemente porque se haya solicitado la reversión de una transferencia. Verifica que la reversión se haya creado, que se haya completado con éxito y que aparezca en el saldo de Stripe. Si se gana la disputa, Stripe devuelve el importe disputado a través de una fila dispute_reversal; revierte la pérdida por contracargo y gestiona por separado cualquier comisión por disputa que Stripe no devuelva. Nordlet relaciona las filas de contracargo utilizando el charge_id de un cargo previamente vinculado, ya sea del mismo archivo o de una importación anterior.

Un ejemplo práctico de liquidación

Imagina un lote de pago automático. El informe detallado contiene:

• Una fila de charge: importe bruto 100.00, comisión de Stripe 3.20, neto 96.80
• Una fila de platform_earning: 15.00, la comisión de la plataforma
• Una fila de transfer: 81.80 al vendedor conectado
• Una fila de refund de una venta anterior: importe bruto 20.00, que se liquida en este lote
• Una fila de payout: el total del lote transferido al banco

La composición del pago, siguiendo la identidad de liquidación de Stripe:

Gross charges                100.00
- refunds                     20.00
- Stripe fees                  3.20
- transfers                   81.80
= net to platform balance     -5.00

La fila de platform_earning no mueve dinero por segunda vez. Indica los 15.00 que permanecen en el saldo de la plataforma una vez descontada la comisión y la transferencia al vendedor, lo que permite a la plataforma reconocer los ingresos por comisiones en lugar de tener que inferirlos.

En este caso, la transferencia al vendedor más el reembolso superan la actividad neta de los cargos, por lo que el lote arroja un saldo neto ligeramente negativo que reduce el siguiente pago o recurre al saldo disponible. El diario registrado revierte la cuenta por cobrar reembolsada, reconoce 15.00 en ingresos por comisiones, registra 3.20 en gastos por comisiones, reduce el pasivo con el vendedor por el importe de la transferencia y contabiliza la reversión del reembolso. La línea bancaria coincide con el importe neto que llega a la cuenta. Ninguna cifra por sí sola equivale a "ingresos", y de eso se trata.

Importa y registra a través del endpoint de liquidación de Nordlet

Para la conciliación a nivel de pagos, utiliza:

POST /v1/bank/settlements/import

proporcionando el proveedor Stripe y el archivo CSV detallado. Nordlet agrupa las filas por automatic_payout_id, convierte cada pago en un lote de liquidación con los totales brutos, de comisiones y netos, omite las reimportaciones de un pago ya registrado, descarta las filas de payout de la composición de la liquidación y vincula automáticamente las filas de cargos, reembolsos y disputas utilizando referencias de pedidos, facturas, PaymentIntent, cargos, orígenes o metadatos. Stripe divide el informe detallado en un archivo por sección, por lo que debes importar los archivos de cargos, reembolsos y comisiones conjuntamente: las filas pertenecientes a un pago que ya se ha importado pero aún no se ha registrado se fusionan en el lote existente. Este es un flujo de trabajo de importación y registro basado en archivos y endpoints de liquidación, no un conector de Stripe en tiempo real; la página de características detalla lo que abarca el módulo bancario y de liquidaciones.

Realiza la vinculación en este orden: cargos a facturas, reembolsos a los cargos originales, disputas a los cargos originales y filas de comisiones al tratamiento de comisiones correspondiente. Mantén las comisiones de Stripe, los ajustes, las reservas y las filas de pagos fuera de la vinculación de facturas. El glosario de conciliación de pagos de Nordlet establece que las líneas de comisiones y ajustes no se pueden vincular a las facturas por diseño; desvía los elementos monetarios no resueltos a cuentas transitorias. La corrección manual se realiza mediante bank/settlements/match { lineId, invoiceId }, utilizando un valor null en invoiceId para desvincular.

A continuación, registra un lote equilibrado:

POST /v1/bank/settlements/post

Esto crea un único diario equilibrado, liquida las facturas vinculadas, debita la cuenta contable del banco por el importe neto del pago, debita las comisiones, acredita las cuentas por cobrar por los cargos, revierte las cuentas por cobrar por reembolsos y contracargos, divide los cargos de marketplace no vinculados entre ingresos por comisiones y cuentas por pagar a vendedores cuando se proporciona commissionPercent, y envía los importes no resueltos a cuentas transitorias. Cualquier categoría que el sistema no reconozca también terminará en una cuenta transitoria, y la respuesta incluirá dichas categorías en una advertencia en lugar de absorberlas silenciosamente.

Lista de comprobación de conciliación

Ejecuta estas comprobaciones antes de cada cierre:

• No existen valores duplicados de balance_transaction_id
• No existen lotes de liquidación duplicados de (provider, payout_id)
• La suma de los importes netos de las líneas es igual al importe neto del lote
• El importe neto del lote es igual al pago bancario, sujeto a las políticas temporales y de divisa
• Cada reembolso tiene un cargo original o una excepción registrada
• Cada disputa tiene una referencia de disputa o de cargo
• Cada transferencia tiene un ID de cuenta conectada
• Cada fila de platform_earning tiene un tratamiento de comisiones definido
• La cuenta transitoria está a cero o ha sido totalmente revisada, incluyendo cualquier categoría no reconocida mencionada en la advertencia de registro
• La cuenta por pagar a vendedores no es negativa a menos que exista una política aprobada de anticipos o recuperaciones
• Los lotes registrados no se pueden reimportar ni volver a registrar silenciosamente
• Un pago en una divisa distinta a la divisa base de la empresa se convierte al tipo de cambio de la fecha del pago, registrándose la diferencia con respecto al tipo de cambio propio de cada factura como una ganancia o pérdida por tipo de cambio realizada; un pago que combine divisas se rechaza en la importación
• Concilia a tres niveles: por fila (cada transacción conserva su ID, categoría, importe, divisa y origen), por pago (los netos detallados coinciden con el pago de Stripe y el recibo bancario) y por libro mayor (el diario registrado cuadra y genera las posiciones previstas de ingresos, comisiones, cuentas por cobrar, pasivos con vendedores y cuentas transitorias). Específicamente para los saldos de los vendedores, verifica que el saldo inicial de cuentas por pagar a vendedores más la nueva parte del vendedor, menos las transferencias y las reversiones válidas, es igual al saldo final de cuentas por pagar a vendedores.

El error recurrente en todos los libros mayores de marketplaces es el mismo con el que empezamos: reducir un pago estructurado a una sola cifra. Mantén los componentes separados, vincula cada uno a un identificador estable de Stripe y utiliza cuentas transitorias para retener todo aquello que aún no puedas explicar. Un cierre limpio es en lo que confiará un auditor.

FAQ

¿Es el pago de Stripe el ingreso de la plataforma?

No. El pago es el neto de los cargos, reembolsos, comisiones de tramitación, transferencias a vendedores, disputas y ajustes que se han liquidado en el mismo lote. Registrarlo como una única línea de ingresos borra el pasivo con el vendedor y el gasto de tramitación que contiene. En el caso de un marketplace con modelo de agencia, los ingresos son la comisión, que identifican las filas de platform_earning.

¿Contra qué informe de Stripe debo conciliar?

Contra el informe de conciliación de pagos detallado (Payout reconciliation, itemized), ya que ofrece una fila por transacción de saldo con una categoría de informe (reporting_category), un automatic_payout_id y los importes brutos, de comisiones y netos. Un resumen de pagos del Dashboard solo demuestra el total del lote. Cuando los pagos automáticos no estén habilitados, utiliza el informe de saldos en su lugar.

¿Debe registrarse una transferencia a un vendedor como un gasto?

No. La parte correspondiente al vendedor se convierte en un pasivo en el momento en que se recibe el cargo del cliente, y la transferencia cancela ese pasivo. Registrar las transferencias como gastos duplica el coste y deja el saldo por pagar al vendedor permanentemente sobreestimado.

¿Qué ocurre con una fila de Stripe cuya categoría no es reconocida por el importador?

Se registra en la cuenta transitoria de liquidación, por defecto la 4440, y la respuesta del registro devuelve una advertencia con los nombres de las categorías que han ido a parar ahí. Las reservas y los ajustes inusuales suelen terminar de esta manera, lo cual es intencionado: el dinero permanece visible y el diario se mantiene equilibrado hasta que alguien decide a qué cuenta pertenece.

¿Cómo se gestionan los reembolsos que se liquidan en un pago posterior?

Llegan como una fila de refund en el informe detallado del pago posterior y se vinculan al cargo original a través del charge_id del cargo vinculado previamente. Un reembolso sintetizado a partir de una exportación de pagos a nivel de cargos es solo una aproximación en este caso, por lo que el informe detallado es la fuente más segura.

Lecturas adicionales

• Importaciones bancarias y de pagos, incluida la conciliación de liquidaciones de Stripe
• Conciliación de pagos: cómo relacionar los pagos de pasarelas con el libro mayor
• Submayores de vendedores en marketplaces: ingresos frente a cuentas por pagar
• Cómo funcionan los cargos en una integración de Connect (Stripe)