Subcuentas de vendedores en marketplaces: Ingresos frente a cuentas por pagar
Una guía práctica para separar el efectivo de los clientes, la comisión de la plataforma, las cuentas por pagar a vendedores, las reservas y los pagos mediante asientos contables equilibrados y un modelo de datos funcional desde el pedido hasta el pago.
El error más común en la contabilidad de un marketplace consiste en tratar el pago bruto del comprador como un ingreso de la plataforma. Un cliente paga 100 €, esa cantidad ingresa en la cuenta de la pasarela de pagos y alguien registra el total como ventas. Los libros cuadran durante un tiempo, los ingresos parecen magníficos y, de repente, un auditor pregunta dónde está el pasivo con el vendedor. No existe, porque los 90 € del vendedor nunca se registraron como una deuda.
La solución es estructural, no cosmética. Un marketplace necesita un modelo de libro mayor que separe cinco fondos distintos desde el primer asiento: el efectivo de los clientes en tránsito, los ingresos por comisiones de la plataforma, las cuentas por pagar a los vendedores, las comisiones de procesamiento y las reservas. Los pagos son un sexto evento que liquida la cuenta por pagar, no un evento de ingresos o gastos por sí mismo. Esta guía muestra los asientos equilibrados y el modelo de datos que mantienen dichos fondos diferenciados.
Comience por la conclusión sobre el rol de principal frente a agente
Antes de que importe cualquier estructura de cuentas, la plataforma debe decidir qué está vendiendo. De acuerdo con la norma ASC 606, esto se evalúa para cada bien o servicio específico, y el resultado determina si los ingresos se reconocen por el importe bruto o neto. Una plataforma puede actuar como principal en un flujo y como agente en otro.
En una venta típica de marketplace correspondiente a los productos de un vendedor, la plataforma suele ser un agente. Se encarga de que el producto del vendedor llegue al comprador, no asume el riesgo de inventario y su contraprestación es una comisión. La guía de Deloitte sobre principal frente a agente bajo la norma ASC 606 estructura el análisis en torno al control: la responsabilidad de cumplir la promesa, el riesgo de inventario y la discreción en los precios son indicadores, no una lista de comprobación que invalide la evaluación de control subyacente.
El motivo por el cual esto debe reflejarse en el diseño del libro mayor, y no quedarse en un simple memorando, es que dicha conclusión determina cada asiento posterior. Si la plataforma actúa como agente, la parte del vendedor constituye un pasivo en el momento en que se devenga. Si actúa como principal en un servicio de logística o de garantía, esa parte corresponde a los ingresos de la plataforma. Almacene esta conclusión como datos estructurados:
principal_agent_rolespecified_good_or_servicecommission_rule_idcontrol_assessment_versioneffective_from/effective_to
Cualquier auditor que revise una línea de comisión neta dos años después debe poder comprobar por qué no se utilizó el importe bruto. Tal como señala BillingPlatform sobre la ASC 606 (principal vs agent), la etiqueta de "marketplace" no resuelve la cuestión por sí sola. Lo hace el análisis de control.
Defina el saldo del vendedor antes de escribir una sola regla contable
El "saldo del vendedor" no es una única cifra. Un vendedor puede tener un saldo histórico acumulado excelente y, al mismo tiempo, no disponer de nada para cobrar porque el dinero sigue pendiente o retenido en reserva. Si unifica estos estados, informará erróneamente tanto de lo que el vendedor puede retirar como de lo que la plataforma todavía le debe.
Como mínimo, debe realizar un seguimiento de:
- Pendiente: devengado o recaudado, pero aún no elegible para su pago.
- Disponible: elegible para su pago según las normas de la plataforma.
- Reservado: retenido para hacer frente a posibles reembolsos, disputas o devoluciones de cargos (chargebacks).
- Pagado: transferido o enviado para su liquidación.
- Negativo: importe que el vendedor debe a la plataforma, recuperable de futuros ingresos.
- Transitorio (suspense): recibido, pero cuyo vendedor o tratamiento aún no se ha determinado.
Los proveedores de pagos ya modelan esta distinción. Stripe separa cada cuenta conectada en saldos pendientes y disponibles, y mantiene un saldo de reserva a nivel de plataforma para ciertos saldos negativos de vendedores. Si el procesador hace esta distinción, el libro mayor también debe hacerla; de lo contrario, la conciliación nunca cuadrará.
El plan de cuentas y las dimensiones relevantes
Una estructura inicial viable mantiene separadas las cuentas de compensación, los pasivos y los ingresos, e incluye una dimensión de vendedor en cada asiento contable relevante.
| Propósito | Cuenta o dimensión | Tratamiento |
|---|---|---|
| Fondos de la pasarela pendientes de liquidación | Compensación de la pasarela de pagos | Activo de compensación |
| Pagos de la pasarela ya ingresados en el banco | Banco | Activo |
| Importe devengado al vendedor pero no pagado | Cuentas por pagar a vendedores | Pasivo |
| Detalle a nivel de vendedor | Dimensión seller_id |
Detalle del pasivo, no ingresos |
| Comisión de la plataforma | Ingresos por comisiones | Ingresos |
| IVA o impuestos sobre las ventas | Impuestos por pagar | Pasivo |
| Comisiones de la pasarela de pagos | Gastos de procesamiento de pagos | Gastos |
| Reservas de vendedores | Pasivo por reservas | Depende del contrato |
| Reembolsos | Menos ingresos (contra-ingreso) o reembolsos | Revierte el tratamiento original |
| Devoluciones de cargos (chargebacks) | Pérdida, cuenta por cobrar o recuperación del vendedor | Depende de quién asuma la pérdida |
| Pagos pendientes de confirmación bancaria | Compensación de pagos a vendedores | Cuenta de compensación |
| Importes no asignados | Transitorio (suspense) | Excepción temporal |
Cada asiento relevante debe incluir el vendedor, el pedido, el lote de pago, la pasarela, la divisa, la entidad jurídica, el tratamiento fiscal, el tipo de evento, la referencia externa y cualquier vínculo de reversión. Sin estos datos, el libro auxiliar de vendedores no puede justificar un saldo individual y el libro mayor no puede justificar el total.
Puede implementar este libro auxiliar utilizando una cuenta de pasivo por cada vendedor, una cuenta agregada de cuentas por pagar con seller_id como dimensión, o bien dividiéndolo entre cuentas por pagar, reservas y compensación de pagos. El enfoque de cuenta agregada con dimensiones escala mucho mejor una vez que se superan unas pocas docenas de vendedores. Elija el modelo junto con su contable, ya que las normas de salvaguarda de fondos y la regulación local de pagos pueden influir en la forma en que deben presentarse los fondos. En cuanto a la operativa de los asientos, nuestro artículo sobre APIs de libro mayor de partida doble para la contabilidad de marketplaces detalla los componentes básicos sobre los que se sustenta este modelo.
Registre la venta separando las líneas del vendedor y de la plataforma
Tomemos como ejemplo una venta en la que se actúa como agente: el cliente paga 100 €, la comisión de la plataforma es de 10 € y el vendedor gana 90 €. En el momento en que se devengan la comisión y el derecho del vendedor:
| Cuenta | Debe | Haber |
|---|---|---|
| Compensación de la pasarela de pagos | 100 € | |
| Cuentas por pagar a vendedores - Vendedor A | 90 € | |
| Ingresos por comisiones | 10 € |
El control fundamental: los 90 € se abonan en una cuenta de pasivo, no en ingresos. La plataforma reconoce 10 €. Este es el resultado que persigue el ejemplo de marketplace de la norma ASC 606 para el caso de un agente, donde la plataforma reconoce su comisión en lugar de la cifra de ventas total del vendedor.
Si los impuestos se recaudan por separado, añada la línea de impuestos por pagar y ajuste la cifra del vendedor o de la plataforma según la conclusión fiscal aplicable. Nunca agrupe los impuestos dentro de la comisión o de la cuenta por pagar al vendedor por motivos de comodidad.
Mantenga las comisiones de la pasarela fuera del cálculo de ingresos y cuentas por pagar
Hay tres conceptos que se suelen confundir constantemente: la comisión de la plataforma, la comisión de la pasarela de pagos y el importe del pago. Son distintos y afectan a cuentas diferentes.
Un cliente paga 100 €, la comisión es de 10 € y la pasarela retiene 3 €.
- Los ingresos por comisiones siguen siendo 10 € si así lo establece el contrato.
- La comisión de la pasarela de 3 € constituye un gasto.
- La cuenta por pagar al vendedor es de 90 €, a menos que el contrato estipule que el vendedor asume el costo de procesamiento. Solo en ese caso se reduce a 87 €, registrando un cargo de 3 € al vendedor.
Registrar únicamente los 97 € netos que llegan al banco elimina en un solo paso la venta bruta, la comisión y la tarifa. Nuestra guía de referencia sobre conciliación de pagos defiende el mismo principio: desglose la liquidación, trate las comisiones de la pasarela como gastos y nunca permita que el depósito neto sustituya a los ingresos.
Modele la disponibilidad, las reservas y los pagos como eventos separados
El dinero cambia de estado varias veces entre el cobro y la liquidación efectiva. Cada transición merece su propio asiento, y una reserva nunca debe considerarse una reducción de ingresos sin explicación.
Cuando los fondos disponibles pasan a estar en reserva:
| Cuenta | Debe | Haber |
|---|---|---|
| Cuentas por pagar a vendedores - Vendedor A | 15 € | |
| Pasivo por reservas de vendedores | 15 € |
Cuando se libera la reserva, se realiza el asiento inverso. La obligación total del vendedor no ha cambiado; lo que ha cambiado es su estado. Stripe documenta las transacciones de reserva que incrementan y liberan fondos, así como las transferencias de cobro para saldos negativos de larga duración, razón por la cual estos movimientos requieren cuentas identificables en lugar de un único asiento neto.
Los pagos (payouts) se gestionan mediante un proceso de dos pasos. En el momento de la aprobación:
| Cuenta | Debe | Haber |
|---|---|---|
| Cuentas por pagar a vendedores - Vendedor A | 90 € | |
| Compensación de pagos a vendedores | 90 € |
En el momento de confirmarse la liquidación bancaria:
| Cuenta | Debe | Haber |
|---|---|---|
| Compensación de pagos a vendedores | 90 € | |
| Banco | 90 € |
Si el pago falla, se revierte la compensación devolviendo el importe a la cuenta por pagar del vendedor. Un pago es la liquidación de un pasivo, no un gasto. Tratarlo como un gasto duplicaría el registro frente a la venta que ya generó dicha cuenta por pagar. Stripe separa el estado del pago (pending, in_transit, paid, failed, canceled) y la fecha prevista de llegada respecto a la fecha de inicio, y estas marcas temporales no deben fusionarse en una sola.
El modelo de datos desde el pedido hasta el pago
El libro auxiliar funciona a base de eventos, no del estado actual del pedido en la aplicación. Cada evento que afecta a un vendedor incluye la misma estructura de datos:
seller_id,event_id,order_idevent_type(venta, reembolso, devolución de cargo, retención de reserva, liberación de reserva, pago, ajuste)effective_date,posting_datecurrency,direction,gross,commission,fees,reserverefund_ref/dispute_refpayout_batch_idreversal_ofsource_status,idempotency_key
A partir de dichos eventos se calcula el saldo de cierre en lugar de almacenar un campo mutable:
Saldo de cierre del vendedor
= saldo de apertura
+ créditos al vendedor
− débitos al vendedor
− pagos realizados
± movimientos de reservas
± correcciones
Cada evento externo necesita una clave de idempotencia (idempotency key) duradera para que los reintentos y los webhooks duplicados no acrediten dos veces a un vendedor ni dupliquen un pago. Patrones recomendados:
- Evento de diario del vendedor:
seller_id:order_id:event_type:version - Lote de pagos:
processor:payout_id - Evento de la pasarela:
processor:event_type:processor_event_id
Las directrices sobre webhooks de Stripe advierten explícitamente de que se producen eventos duplicados, por lo que la detección de duplicados no es opcional. Los asientos registrados permanecen inmutables. Las correcciones se realizan mediante un asiento de reversión seguido de un asiento corregido, y es la propia estructura del evento la que transporta el enlace reversal_of y el motivo. El libro mayor almacena los asientos, no dicho enlace: Nordlet ofrece operaciones de creación, consulta y listado para las transacciones del libro diario en su referencia de la API sin opciones de actualización ni eliminación, por lo que una corrección siempre genera una nueva transacción en lugar de modificar una existente.
Los reembolsos y devoluciones de cargo se vinculan, nunca flotan
Un reembolso que aparece en la liquidación de la semana siguiente nunca debe convertirse en una nueva venta negativa asociada a dicho pago. Debe vincularse a la transacción original y preservar la asignación inicial al vendedor. Según lo estipulado en el contrato:
- Se revierte la comisión si el contrato establece que es reembolsable.
- Se carga en la cuenta por pagar del vendedor si este asume el reembolso.
- Se carga en una cuenta de pérdidas de la plataforma si esta asume el costo.
- Se incrementa una reserva mientras la disputa esté abierta, liberándola o utilizándola al resolverse.
Las devoluciones de cargos (chargebacks) posteriores al pago son el origen de los saldos negativos. Como el dinero del vendedor ya ha sido transferido, la plataforma o bien lo recupera de ingresos futuros o asume la pérdida. El modelo debe permitir saldos negativos en los vendedores y definir la regla de recuperación aplicable. Los informes de marketplace de Adyen muestran cómo los reembolsos y devoluciones de cargos generan líneas de débito separadas por titular de cuenta, que es el nivel de granularidad al que se debe aspirar.
Concilie por cada pago, no por mes
Desglose cada liquidación de la pasarela antes de contabilizarla y concilie cada pago individual en lugar de agregar todo un mes:
Cargos brutos
− reembolsos
− comisiones de la pasarela
− devoluciones de cargos (chargebacks)
± reservas y ajustes
= pago neto de la pasarela
A continuación, compruebe que coinciden cuatro saldos para cada vendedor y divisa: el libro auxiliar del vendedor, el saldo del vendedor en la pasarela, el informe de pagos y la cuenta de compensación bancaria. Cuando difieran, clasifique la discrepancia (desfase temporal, evento faltante, duplicado, asignación incorrecta, divisa errónea, pago fallido o devolución de cargo asignada a la parte incorrecta). Compensar las diferencias de forma neta provoca que los errores se oculten entre sí y persistan hasta el cierre del periodo.
Agregar un mes completo permite que las diferencias temporales se compensen y oculta desviaciones reales. La conciliación por cada pago, utilizando como clave el identificador del pago y la referencia de la transacción en lugar del importe y la fecha, permite detectarlas a tiempo.
Patrones de error habituales
| Tipo de error | Por qué es problemático | Control |
|---|---|---|
| Pago bruto del cliente contabilizado como ingreso | Infla los ingresos y oculta el pasivo con el vendedor | Separar las cuentas por pagar y la comisión en el momento del devengo |
| Contabilización exclusiva de los depósitos netos | Se pierden el importe bruto, las comisiones, los reembolsos y las reservas | Desglosar cada liquidación |
| Pago registrado como gasto | Refleja incorrectamente la liquidación de un pasivo | Cargar en cuentas por pagar al vendedor al realizar el pago |
| Un único campo de saldo por vendedor | Mezcla saldos pendientes, disponibles, reservados y pagados | Rastrear explícitamente los estados del saldo |
| Comisión calculada en el momento del pago | Los ingresos quedan vinculados a la programación de pagos | Reconocer la comisión cuando se devenga |
| Reserva tratada como reducción de ingresos | Oscurece el calendario y el riesgo | Rastrear retenciones, liberaciones y consumo por separado |
| Reembolso aplicado al último pago | Rompe la atribución del pedido | Vincular el reembolso a la transacción original |
| Modificación de asientos ya registrados | Destruye la pista de auditoría | Revertir y volver a registrar |
| Webhooks reproducidos | Créditos y pagos duplicados | Claves de idempotencia y detección de duplicados |
| Coincidencia basada únicamente en importe y fecha | Colisión entre elementos distintos | Coincidir por ID de pago, ID de transacción, vendedor y divisa |
Por dónde empezaría
Mapee el flujo del dinero antes de tocar el plan de cuentas. Anote cada evento desde el cobro del pago hasta la liberación de la reserva, e identifique cuáles generan ingresos, cuáles crean un pasivo y cuáles únicamente cambian de estado.
A continuación, diseñe un flujo completo de principio a fin y compruebe que cuadra: una venta normal, un reembolso parcial, una devolución de cargo posterior al pago, una reserva retenida y liberada, y un pago fallido. Ejecute estas operaciones con saldos previstos conocidos. Si la cuenta de control de cuentas por pagar a vendedores coincide con la suma del libro auxiliar, la compensación de la pasarela concuerda con el informe de liquidación y el depósito bancario coincide con el identificador del pago, dispondrá de una estructura sólida.
Active el cierre de periodos contables únicamente después de que el primer mes cierre de forma limpia con un saldo transitorio en cero. Bloquear los periodos demasiado pronto solo sirve para congelar errores.
Nordlet registra las liquidaciones siguiendo estos principios de forma nativa: la comisión de la plataforma se destina a ingresos por comisiones, la parte del vendedor a cuentas por pagar, las tarifas de la pasarela a gastos de procesamiento de pagos y cualquier concepto no asignado a una cuenta transitoria. Los periodos del libro mayor permanecen abiertos hasta que se cierren de forma explícita, por lo que el primer mes puede cerrarse una vez que la cuenta transitoria esté a cero. La página de características detalla todo lo que incluye.
FAQ
¿El pago del comprador es en algún caso un ingreso de la plataforma?
Solo en el caso de aquellos bienes o servicios específicos en los que la plataforma actúe como principal. En una venta de marketplace donde se actúa como agente respecto a los productos del vendedor, los ingresos corresponden a la comisión y la parte del vendedor constituye un pasivo. Una plataforma puede actuar como principal en un servicio de logística y como agente en los bienes subyacentes dentro de un mismo pedido, por lo que la evaluación debe realizarse por cada bien o servicio específico, no por empresa.
¿Deben las reservas reducir los ingresos?
No. Una reserva es una asignación de riesgo y de calendario, no un ajuste de ingresos. Los fondos deben transferirse desde las cuentas por pagar a los vendedores a un pasivo por reservas en el momento de la retención, revirtiendo dicho asiento al liberarlos. Los ingresos y las comisiones no se ven afectados por el hecho de que el dinero del vendedor se encuentre retenido temporalmente.
¿Cómo puedo evitar pagos duplicados derivados de reintentos de webhooks?
Asocie una clave de idempotencia a cada evento externo, como processor:payout_id para los lotes de pagos, y detecte eventos duplicados en el momento de la escritura. Los proveedores advierten explícitamente de que se producen entregas duplicadas de webhooks, por lo que el libro mayor debe rechazar el segundo intento en lugar de registrarlo de nuevo.
¿Puede el saldo de un vendedor volverse negativo?
Sí, y el modelo debe permitirlo. Una devolución de cargo (chargeback) que llega después de que el vendedor haya recibido su dinero deja a la plataforma con una cuenta por cobrar frente al vendedor o con una pérdida que debe asumir. Ocultar los saldos negativos solo sirve para enmascarar una obligación no registrada.
¿Por qué se debe conciliar cada pago en lugar del total mensual?
Porque las diferencias temporales y los errores se anulan al agregar un mes completo, de modo que los totales pueden cuadrar aunque las transacciones individuales sean incorrectas. La conciliación por cada pago, cruzando identificadores de pago y de transacción, permite detectar eventos faltantes, duplicados y devoluciones de cargo mal asignadas antes del cierre.