Cliente → Provider
Pago de la actividad y, cuando corresponda, gastos de gestión trasladados al cliente.
Documento de arquitectura funcional y fiscal
Modelo objetivo para separar correctamente los cobros de las reservas, las comisiones de los Agentes y los servicios facturados por Trivity.
00
Cada concepto conserva su propia causa, factura, acreedor y trazabilidad.
Pago de la actividad y, cuando corresponda, gastos de gestión trasladados al cliente.
Comisión comercial generada por las reservas canalizadas por ese Agente.
Comisión de distribución, gastos de gestión y servicio de cobro de facturas del Agente.
Estos circuitos no se confunden ni se compensan entre sí. El pago técnico puede coordinarse, pero la documentación fiscal de cada operación permanece separada.
01
La reserva fija una fotografía económica que no depende de configuraciones futuras.
En el momento de crear o validar la reserva se guardan como snapshots:
PVP × porcentaje del Agente.La comisión se genera cuando la reserva alcanza el estado económico definido, actualmente su validación. Por ello puede existir también en reservas con pago presencial o externo.
02
El Provider es el titular económico del cobro de la actividad.
En pagos presenciales no existe gasto de pasarela de Stripe asociado a la reserva, aunque pueden seguir generándose la comisión del Agente y la comisión de distribución de Trivity.
03
Los eventos contables se registran antes de agruparse en facturas.
agent_commission_events registra cada devengo, ajuste o anulación. Cada evento se asigna una sola vez a la ruta manual o automática, que permanece inmutable.
trivity_fee_ledger registra la comisión de distribución, los gastos de gestión ya cobrados y sus ajustes. No se sobrescriben importes: se añaden movimientos compensatorios.
04
El circuito existente se conserva aislado de la automatización.
05
La automatización solo se activa cuando el Agente completa todos los requisitos.
El Agente sigue siendo el expedidor y responsable fiscal de sus facturas. Trivity actúa como tercero que las confecciona bajo mandato. Si cada camping factura por separado, cada uno necesita su propia entidad fiscal, serie, mandato y cuenta conectada.
06
El día 1 se cierra el mes natural anterior.
Los eventos automáticos se agrupan por Agente, Provider y moneda. Para cada pareja se genera una factura fiscal del Agente al Provider con las reservas y ajustes incluidos en el período.
Ejemplo
07
El cargo se realiza directamente en la cuenta conectada del Agente.
application_fee_amount.Continuación del ejemplo
El cargo pertenece a la cuenta del Agente. La atribución exacta de las tarifas de Stripe depende de la configuración efectiva de su cuenta Express y debe verificarse antes de cada ejecución.
08
Documenta fiscalmente la tarifa retenida mediante la application fee.
Por cada factura Agente → Provider cobrada, Trivity emite al Agente su propia factura por el servicio de gestión y cobro. El total es el 2,5 % retenido y se desglosa extrayendo base e IVA.
En el ejemplo anterior, Trivity factura 0,25 EUR, impuestos incluidos. Esta factura es independiente tanto de la factura del Agente como de las comisiones que Trivity facture al Provider.
09
Una sola factura mensual reúne los conceptos propios de Trivity.
La factura contiene líneas diferenciadas para:
El documento muestra el total fiscal, el importe ya retenido y el saldo pendiente. El cobro off-session mensual se limita al saldo pendiente; nunca vuelve a cobrar los gastos ya retenidos.
Ejemplo completo para una reserva de 100 EUR
En paralelo, el Provider paga los 10 EUR de la factura del Agente y Trivity retiene 0,25 EUR al Agente por gestionar su cobro. Son operaciones y facturas distintas.
10
Las correcciones se registran con deltas y documentos rectificativos.
Los eventos positivos y negativos se compensan en el período. Si el neto es cero, no se emite factura por esa pareja.
La factura original no se modifica. Se generan facturas rectificativas, devoluciones sobre el cargo original y, cuando proceda, devolución proporcional de la application fee.
11
Un cobro que exige autenticación queda pendiente, no fallido definitivamente.
requires_action y se conserva el mismo PaymentIntent.client_secret se entrega temporalmente al cliente autorizado y no se persiste.12
La factura es un registro fiscal estructurado; el PDF es solo su representación.
El régimen general español del 21 % puede automatizarse. Exenciones, operaciones intracomunitarias, inversión del sujeto pasivo u otros regímenes exigen configuración fiscal explícita; si falta, el cierre se bloquea para revisión.
13
Cada obligación se acepta por quien puede vincular jurídicamente a la empresa.
Las facturas del Agente disponen del procedimiento de revisión u objeción definido contractualmente, incluida la aceptación por silencio cuando sea jurídicamente aplicable.
14
La elegibilidad se revalida justo antes de emitir o cobrar.
charges_enabled y payouts_enabled.controller, costes, pérdidas y responsabilidades compatible.15
Arquitectura implementada progresivamente, todavía fuera de producción.
Modelo económico, separación manual/automática, consentimientos, ledger, cierres, facturas, cobros directos, application fees, recuperación SCA y controles de seguridad.
Configuración live, webhooks, índices y migraciones, validación fiscal final, límites, simulación integral, piloto controlado y despliegue coordinado de backend, apps y textos legales.