En resumen: hay tres formas de conectar Amazon y NetSuite: el NetSuite Connector de Oracle, la integration app Amazon–NetSuite de Celigo o un desarrollo a medida contra la Selling Partner API (SP-API). La adecuada depende de sus marketplaces, de su programa FBA, de su volumen, de cómo quiere finanzas que se contabilicen las ventas y las comisiones y de quién lo va a mantener. Primero mapeamos los flujos; después elegimos.
Cuando Amazon y NetSuite no se hablan
Suele empezar por un pequeño paso manual que nunca desaparece. Reconocerá algunos de estos:
- Los pedidos de Amazon se vuelven a teclear, o se importan por lotes desde un fichero.
- El stock de Amazon y el de NetSuite no coinciden, así que vende de más una referencia y se queda con exceso de otra.
- Los planificadores no ven cuánto stock FBA hay en cada país de almacenamiento de Amazon.
- Las liquidaciones se contabilizan como una sola cifra, de modo que las ventas brutas y las comisiones no se ven.
- Las devoluciones y los reembolsos de Amazon no son tarea de nadie, así que nunca se registran.
- Varios marketplaces informan en monedas distintas, y las diferencias se absorben en algún sitio.
La deriva del stock rara vez es cuestión de velocidad; explicamos por qué el stock se desvía entre canales. Las decisiones de diseño que siguen son lo que lo arregla.
Seller o Vendor, FBA o FBM: qué cambia en la integración
El modelo bajo el que vende decide qué entra en NetSuite, así que defínalo antes de elegir la vía.
| Modelo | Quién tiene el stock | Qué entra en NetSuite | Quién envía | Qué vuelve |
|---|---|---|---|---|
| Seller Central, FBA | Amazon, en sus centros logísticos | Pedidos de venta o facturas a partir de los pedidos de Amazon; niveles de stock FBA para tener visibilidad | Amazon | Devoluciones, reembolsos, reintegros |
| Seller Central, FBM (MFN) | Usted | Pedidos de venta; su stock es la fuente de verdad | Usted o su 3PL | La expedición y el seguimiento vuelven a Amazon; las devoluciones llegan |
| Vendor Central (1P) | Amazon, después de comprarle | Pedidos de compra de Amazon, que usted factura | Usted | Confirmaciones de envío, facturas, contracargos |
| Multi-Channel Fulfilment (MCF) | Amazon, que sirve pedidos de otros canales | Pedidos de sus otras tiendas, como Shopify | Amazon | El seguimiento vuelve a la tienda de origen |
Vendor Central es otro flujo: Amazon le envía pedidos de compra, por EDI o por API, y usted factura a Amazon, en lugar de recibir pedidos de clientes finales. Casi todo lo que sigue trata de Seller Central, que es por donde empiezan la mayoría de las marcas europeas.
Qué sincronizamos entre Amazon y NetSuite
| Flujo | Dirección | Qué cubre |
|---|---|---|
| Pedidos | Amazon → NetSuite | Pedidos MFN y FBA con marketplace, moneda e impuestos tal como los informa Amazon |
| Inventario | NetSuite → Amazon en FBM; Amazon → NetSuite en FBA | Cantidad disponible enviada a Amazon en FBM; stock FBA por ubicación recibido para tener visibilidad |
| Listings y precios | NetSuite → Amazon | Precios y disponibilidad, cuando NetSuite es el maestro de artículos |
| Expedición y seguimiento | NetSuite → Amazon | Confirmación de envío y seguimiento de los pedidos MFN |
| Devoluciones, reembolsos y reintegros | Amazon → NetSuite | Notas de crédito y reembolsos, asociados al pedido original; vea devoluciones, reembolsos y facturas rectificativas |
| Liquidaciones | Amazon → NetSuite | Resumen más abajo; el tratamiento completo está en nuestra página de liquidaciones de marketplaces |
Hacer entrar los pedidos es la mitad fácil. Nuestro artículo sobre cuatro formas de llevar los pedidos de ecommerce a su ERP explica las decisiones de arquitectura que hay detrás.
Tres formas de conectar Amazon y NetSuite, y cómo elegimos
| Vía | Mejor cuando | Atención a | Quién la opera |
|---|---|---|---|
| NetSuite Connector (Oracle) | Flujos estándar de Seller Central o Vendor Central, equipo centrado en NetSuite | Procesos que no encajan en sus mapeos estándar; compruebe la cobertura de cada marketplace que use | Su equipo, dentro de NetSuite |
| Integration app Amazon–NetSuite de Celigo | Quiere una app respaldada por el fabricante sobre una plataforma gestionada, ampliada con flujos a medida | Cobertura de marketplaces y límites de edición: los flujos de liquidaciones de Celigo exigen su edición Premium | Una plataforma gestionada, operada por nosotros o por su equipo |
| Desarrollo a medida contra la SP-API | Flujos poco habituales, resumen contable con mucho volumen, packs y kits, enrutado multientidad (OneWorld) | El código es suyo, así que debe estar documentado y monitorizado | Nosotros, o su equipo una vez formado |
NetSuite Connector
El conector prediseñado de Oracle. Su documentación incluye Amazon Seller Central y Amazon Vendor Central entre las tiendas compatibles (NetSuite Connector, Supported Storefronts and 3PLs). Es una opción sólida para flujos estándar cuando el equipo vive en NetSuite. Si cubre todos los marketplaces europeos y sus reglas de packs, devoluciones y multimoneda es algo que debe comprobar con su propia lista antes de comprometerse.
Integration app Amazon–NetSuite de Celigo
Como partner de implementación de Celigo, desplegamos las integration apps prediseñadas de Celigo, esta incluida, configuradas según sus procesos. La app tiene flujos para la importación de pedidos, para la exportación de inventario, precios y expediciones, y para las liquidaciones. Celigo documenta que sus flujos de liquidaciones, que convierten los datos de la liquidación en registros de liquidación personalizados y en cobros de clientes, solo están disponibles en la edición Premium. Sus notas de la versión mencionan varios marketplaces europeos, pero la cobertura cambia según el marketplace y la edición, así que confirmamos cada marketplace en el que vende en la documentación de Celigo, y con Celigo cuando no queda claro, antes de recomendarla. Implementamos Celigo y solo la recomendamos cuando encaja.
Desarrollo a medida contra la SP-API
La Selling Partner API de Amazon por un lado, SuiteTalk y los RESTlets de NetSuite por el otro, en nuestro propio stack: sin licencia de terceros en medio y sin límites de conectores que sortear. Lo elegimos cuando sus flujos son poco habituales, cuando el volumen pide contabilizar resúmenes en lugar de pedido a pedido, cuando los packs y kits necesitan lógica propia o cuando los pedidos deben enrutarse entre varias entidades de NetSuite. Cuando un proceso requiere aprobaciones o varios pasos, añadimos n8n para la orquestación.
Cómo elegimos. La recomendación sigue su volumen, los marketplaces en los que vende, su programa FBA, su modelo de artículos, las reglas de contabilización que quiere finanzas y cualquier iPaaS que ya pague. No somos revendedores, y la respuesta sigue su caso, no una cuota. Para el contraste de arquitecturas más amplio, lea iPaaS, punto a punto y middleware.
¿No tiene claro qué vía encaja? Reserve una llamada de 30 minutos y traiga su configuración actual.
Decisiones de diseño propias de Amazon
Aquí es donde las integraciones con Amazon salen bien o mal. Nada de esto sale de la configuración por defecto de un conector.
Inventario FBA en NetSuite. El stock que tiene Amazon debe aparecer en NetSuite como una ubicación propia o varias, una por país o por programa, o una sola ubicación «Amazon EU», alimentada con los datos de inventario de Amazon y conciliada con sus informes de inventario. Los envíos entrantes a Amazon son traslados desde la ubicación de su almacén a la ubicación de Amazon. Así, los planificadores ven por separado lo que hay en su almacén y lo que hay en el de Amazon, y ninguna de las dos cifras es una suposición.
FBA paneuropeo y varios marketplaces. Con Pan-European FBA, Amazon puede mover su stock entre países, y los pedidos llegan de amazon.es, .de, .fr, .it y otros, en euros y en otras monedas, como corona sueca, esloti polaco o libra esterlina, si vende allí. El diseño debe decidir si el cliente de NetSuite es uno por marketplace o uno por comprador, cómo se registran los movimientos de stock entre países y dónde acaban las diferencias de cambio.
Datos restringidos de compradores. Amazon limita lo que la integración de un vendedor puede leer sobre los compradores: los datos personales son datos restringidos en la SP-API. Los registros de clientes en NetSuite deben diseñarse en torno a esa limitación, no al revés. Consulte los requisitos vigentes de protección de datos para desarrolladores de Amazon para saber qué le aplica; esto no es asesoramiento jurídico.
Contabilización pedido a pedido o resumida. Los vendedores B2C con mucho volumen suelen contabilizar un resumen diario en lugar de cada pedido, lo que mantiene NetSuite ágil y el libro mayor legible. Los vendedores con poco volumen o B2B suelen querer cada pedido. Es una decisión de finanzas, y debe tomarse antes del mapeo.
Mapeo de SKU, ASIN y FNSKU. Un listing de Amazon, una etiqueta logística de Amazon y su propio artículo son tres identificadores de un mismo producto. Los packs y los kits lo complican, porque una venta en Amazon puede consumir varios artículos de NetSuite. Acordamos primero el modelo de artículos.
IVA y OSS. Tener stock en otro país de la UE y vender a través de varios marketplaces puede generar obligaciones de IVA. La integración debe trasladar correctamente los datos fiscales que informa Amazon, y las reglas las fija su asesor fiscal, no nosotros. En España, además, las facturas emitidas a partir de estos datos entran en las normas de facturación electrónica y de remisión de información tributaria (SII, Verifactu), que tratamos aparte.
Liquidaciones: donde fallan la mayoría de las integraciones con Amazon
Amazon paga un importe neto por cada periodo de liquidación, después de comisiones, cargos de FBA, publicidad, reembolsos y reservas. Si la integración lo contabiliza como un solo ingreso, las ventas brutas y las comisiones desaparecen en una única línea y nadie puede decir cuánto gana realmente un canal. Una integración bien hecha divide cada liquidación en ventas, comisiones, reembolsos y pago neto, de modo que el ingreso coincide con la línea del banco y cada comisión tiene su cuenta. Los informes de liquidación antiguos de Amazon, en XML y en fichero plano, se retiran en favor del informe Flat File V2 el 11 de noviembre de 2026, así que un lector pensado para el formato antiguo tiene fecha límite (Amazon SP-API changelog).
A propósito, no repetimos aquí todo el tratamiento. La página de liquidaciones de marketplaces cubre la conciliación multimarketplace, con Amazon, Zalando y Mirakl lado a lado, y nuestro artículo sobre la brecha de conciliación de las liquidaciones de marketplaces explica por qué importa. ¿Vende a través de Amazon y de su propia tienda? Vea también cómo conectamos WooCommerce y Magento.
Cómo se desarrolla un proyecto NetSuite–Amazon
- Descubrimiento. Marketplaces, programa FBA, volúmenes y reglas de contabilización.
- Construcción en sandbox y mapeo. Con sus datos reales, cubriendo los casos límite: devoluciones, packs, varias monedas, stock que se mueve entre países.
- Ejecución en paralelo. Sobre un subconjunto de SKU o de pedidos, comparando con lo que hace hoy.
- Puesta en producción y monitorización. Desplegamos, vigilamos de cerca las primeras sincronizaciones y seguimos a su lado.
El calendario depende de los marketplaces y de la vía, y fijamos alcance y esfuerzo en un blueprint de integración tras el descubrimiento, en lugar de adivinarlos antes.
Después de la puesta en producción: monitorización, errores y responsabilidad
La mayoría de las integraciones no fallan el primer día. Fallan en una semana de mucho trabajo, en silencio, y alguien se da cuenta a fin de mes. Por eso la gestión de errores, los reintentos y las alertas van con la integración, no como un extra que se vende después del primer fallo invisible. En Amazon, las alertas que solemos configurar cubren los fallos de importación de pedidos, los SKU sin mapear, los envíos de inventario rechazados y los descuadres de liquidación.
Lo que construimos es suyo. Documentamos los flujos y, si prefiere operarlos usted, formamos a su equipo. Nuestro artículo sobre la vida después de la puesta en producción explica por qué esta fase decide si una integración dura.
Por qué Atypical Tech
- Profundidad en NetSuite, no solo fontanería. Entendemos los registros, los procesos y las finanzas detrás de cada flujo.
- Solo ingenieros senior. Quien define el alcance de su proyecto es quien lo construye.
- Partner donde ayuda, independientes donde importa. Somos partner de implementación de Celigo y partner de Stacksync, y construimos directamente contra las APIs cuando ninguna plataforma encaja.
- Con base en España, trabajando en toda Europa. En inglés, español, portugués y catalán. Ya operamos integraciones con Shopify, WooCommerce y Magento, y conciliación de liquidaciones de marketplaces. Vea todos los sistemas que conectamos.
Fuentes
- Oracle NetSuite Help Center, NetSuite Connector: Supported Storefronts and 3PLs. Consultado el 7 de octubre de 2026.
- Celigo Help Center, Amazon Seller Central–NetSuite integration app y notas de la versión. Consultado el 7 de octubre de 2026.
- Amazon SP-API, changelog: retirada de los informes de liquidación en XML y en fichero plano. Consultado el 7 de octubre de 2026.