El VAT Transaction Report es uno de esos informes de Amazon que casi todo seller descarga tarde. Hasta que llega el 369. O hasta que intenta entender por qué sus ventas OSS no cuadran con el dinero del settlement. Ahí es cuando aparece el problema real: el reporte existe para clasificar fiscalmente operaciones sujetas a IVA, pero si lo abres sin criterio, parece una sopa de columnas y etiquetas.
La idea de esta guía es quitarle dramatismo. No necesitas memorizar cada columna. Necesitas entender qué te está diciendo el informe, qué no te está diciendo, y por qué no debes mezclarlo con el Settlement Report como si fueran la misma cosa. Si haces esa separación bien, preparar el 369 deja de ser una reconstrucción artesanal y pasa a ser un proceso bastante más controlable.
Qué es el VAT Transaction Report y para qué sirve de verdad
El VAT Transaction Report es el informe de Amazon que desglosa operaciones con lógica fiscal. No está pensado para decirte cuánto te ha pagado Amazon ni cuánto has cobrado neto en el banco. Está pensado para mostrar transacciones con información relevante para IVA: tipo de operación, esquema fiscal aplicado, países implicados, base imponible y cuota.
Si vendes con Amazon FBA en varios países, este reporte te ayuda a separar ventas domésticas, ventas a distancia intracomunitarias, devoluciones y operaciones que no deben acabar dentro del mismo bloque fiscal. Por eso es tan útil para OSS. No porque haga el trabajo por ti, sino porque contiene la materia prima para decidir qué entra en el 369 y qué se queda fuera.
Dicho de otra forma: el VAT Transaction Report te habla en idioma IVA. El Settlement Report te habla en idioma caja y fees. Si intentas usar solo uno de los dos para todo, acabas distorsionando algo.
Dónde se descarga y por qué no conviene pedirlo en el último momento
En Seller Central, este informe suele localizarse en la ruta de Informes → Logística de Amazon → Informe de transacciones sujetas a IVA. La ubicación exacta puede variar según la interfaz y el mercado, pero el nombre operativo es ese. Lo importante no es tanto la ruta como el hábito: descargarlo con tiempo y para el período correcto.
El error clásico es pedir el informe el día antes de presentar el 369 y descubrir que el rango temporal no coincide, que faltan días, o que has mezclado operaciones que no pertenecen al trimestre. En Amazon esto pasa bastante porque el cierre financiero y el cierre fiscal no siempre se miran con la misma lógica. Si además tienes más de un país de almacenamiento o ventas de varios marketplaces, el margen para equivocarte se dispara.
Mi consejo es simple: pide el VAT Transaction Report por período fiscal, no por intuición. Y guárdalo siempre junto con el Settlement Report que vayas a usar para el mismo cierre. Eso te evita cruces absurdos cuando toque revisar ajustes o devoluciones.
Las columnas que más importan para OSS y para revisar el criterio
No todas las columnas pesan igual. Para un seller que quiere declarar bien OSS, hay seis que merecen atención inmediata: TRANSACTION_TYPE, TAX_REPORTING_SCHEME, SALE_DEPART_COUNTRY, SALE_ARRIVAL_COUNTRY, TOTAL_ACTIVITY_VALUE_AMT_VAT_EXCL y VAT_AMOUNT. Con esas seis ya puedes empezar a construir criterio.
TRANSACTION_TYPE
Te dice qué clase de actividad estás viendo. Venta, devolución y otros movimientos no se leen igual. Parece obvio, pero muchos errores vienen de sumar todo lo que "suena a venta" sin diferenciar si esa línea representa una venta efectiva, una reversión o un ajuste. Para declarar bien, primero separa la naturaleza de la operación y luego suma.
TAX_REPORTING_SCHEME
Esta columna es clave porque te orienta sobre el esquema fiscal con el que Amazon está etiquetando la operación. Si estás trabajando el 369, aquí debes prestar mucha atención a las líneas relacionadas con UNION-OSS. Ignorar este filtro es uno de los fallos más caros, porque te lleva a meter en OSS operaciones que no tocan o a dejar fuera operaciones que sí debían ir.
SALE_DEPART_COUNTRY y SALE_ARRIVAL_COUNTRY
Estas dos columnas te cuentan la historia geográfica de la operación. El país de salida y el país de llegada son básicos para decidir si estás ante una venta doméstica o una venta a distancia intracomunitaria. En FBA esto cambia todo. Una venta desde stock en Francia a cliente en Francia no se trata igual que una expedición desde Alemania a un cliente en Italia.
TOTAL_ACTIVITY_VALUE_AMT_VAT_EXCL y VAT_AMOUNT
Aquí tienes la base imponible sin IVA y la cuota de IVA asociada. Son las columnas que terminan afectando al cálculo fiscal, pero solo tienen sentido si antes has clasificado bien el tipo de operación y el esquema. Sumar bases e IVA sin esa limpieza previa es la forma más rápida de declarar importes técnicamente bonitos pero fiscalmente mal ubicados.
Si quieres una lectura más detallada de campos y significados, te conviene revisar también esta guía específica de columnas del VAT Transaction Report.
En qué se diferencia del Settlement Report y por qué necesitas ambos
El Settlement Report y el VAT Transaction Report no compiten. Se complementan. El primero te sirve para entender el flujo económico real: ventas liquidadas, fees, ajustes, reembolsos y saldo que termina en tu payout. El segundo te sirve para entender la clasificación fiscal de operaciones sujetas a IVA. Uno responde a "qué dinero se ha movido". El otro responde a "cómo se ha tratado fiscalmente cada línea".
Esto es especialmente importante en el Modelo 303. Para el 303 te interesan mucho los fees, los cargos de Amazon y la estructura del settlement. Para el 369 te interesa mucho la lógica de IVA por operación y por país. Intentar montar ambos modelos solo con el settlement deja ciegos muchos matices de OSS. Intentar montar ambos solo con el VAT report deja fuera una parte importante de los gastos y la conciliación.
Por eso FBAtax procesa los dos informes juntos: Settlement Report (.txt) y VAT Transaction Report (.csv). No es un capricho del producto. Es porque el problema fiscal real de un seller FBA está repartido entre ambos ficheros.
Errores comunes al leer este informe y cómo evitarlos
El primer error es confundir cualquier operación transfronteriza con OSS. No toda línea internacional acaba en el 369. El segundo error es tratar EXPORT como si fuera una venta doméstica o una venta OSS sin revisar el contexto. El tercero es ignorar REVERSE_CHARGE, cuando precisamente puede estar indicando que la lógica de IVA no es la que estás presuponiendo.
También se ve mucho esto:
- Trabajar sin filtrar por UNION-OSS cuando el objetivo es preparar el 369.
- Usar el país del marketplace como si fuera el país de llegada de la operación.
- Sumar bases sin restar devoluciones o movimientos compensatorios.
- Comparar el VAT report contra el banco en vez de compararlo contra el cierre fiscal.
- Intentar reconstruir todo a mano con filtros distintos cada trimestre.
Para salir de ese bucle, lo mejor es trabajar con una metodología fija. Primero clasificas el esquema fiscal. Después validas países de salida y llegada. Luego separas bases y cuotas. Y solo al final concilias contra el resto de informes. Si empiezas al revés, te pierdes. Si necesitas el mapa general, esta guía sobre qué informes de Amazon usar para OSS te ahorra bastante tiempo.
Cómo lo procesa FBAtax y qué te ahorra en la práctica
FBAtax está diseñado para evitar justo ese trabajo manual repetitivo. Procesa el VAT Transaction Report para leer la lógica de IVA por operación y lo cruza con el Settlement Report para completar la parte económica y de gastos. Con esa base, prepara la salida fiscal útil para un seller español que vende con Amazon FBA.
En concreto, para el 369 genera el fichero TXT en formato BOE conforme a la Orden HAC/610/2021. Para el 303 genera un Excel con las casillas calculadas. Y los modelos 349, 390 y 347 están disponibles en Beta como vista previa orientativa. El valor no está en "tener otro dashboard". Está en no depender de filtros improvisados cada trimestre.
Si ahora mismo estás peleándote con CSV, pivots y una versión distinta de tu Excel cada cierre, probablemente ya has detectado el cuello de botella. Puedes probar FBAtax gratis durante la Beta, sin tarjeta de crédito, y ver si tu proceso encaja mejor con una lectura automática de informes. Para un seller FBA, la mejora no suele venir de saber más teoría. Suele venir de cometer menos errores repetidos.
Y si todavía tienes dudas sobre cuándo una venta debe ir a OSS y cuándo no, te recomiendo enlazar este informe con una revisión previa de cómo funciona OSS para Amazon FBA. Cuando el criterio está claro, el VAT report deja de parecer un archivo hostil y empieza a ser una herramienta útil.
Preguntas frecuentes
¿El VAT Transaction Report sustituye al Settlement Report?
No. El VAT report te ayuda a entender la clasificación fiscal de las operaciones. El Settlement Report te ayuda a entender cobros, fees y conciliación económica. Para trabajar bien 303 y 369, normalmente necesitas ambos.
¿Qué columna suele ser la más importante para preparar OSS?
No hay una sola columna mágica. Lo normal es revisar en conjunto TRANSACTION_TYPE, TAX_REPORTING_SCHEME, SALE_DEPART_COUNTRY, SALE_ARRIVAL_COUNTRY, base imponible sin IVA y VAT_AMOUNT.
¿FBAtax necesita el VAT Transaction Report para calcular el 369?
Sí. FBAtax procesa el VAT Transaction Report junto con el Settlement Report para clasificar operaciones y preparar la salida fiscal del 369 y del 303. Si quieres probarlo, la Beta sigue siendo gratuita.
