Al conectar su sitio de comercio electrónico con el ERP y la facturación electrónica, la decisión se reduce a una pregunta más sencilla de lo que la mayoría de las empresas supone: ¿su tienda está en una de las plataformas que admite un conector listo para usar, o es un desarrollo a medida basado en código propio? Si es lo primero, en la mayoría de los casos basta con un conector listo para usar (como Entegra, Sopyo o Sentos): paga una suscripción mensual más un crédito (kontör) por documento, la puesta en marcha es rápida y la carga de mantenimiento no recae en usted. Si es lo segundo (es decir, si no está en una plataforma con nombre propio, incluida en una lista, como WooCommerce, Shopify o İkas), el “camino feliz” (happy path) de los conectores listos para usar no contempla su caso, y encargar un puente de API a medida (o llamar a la API de un conector desde su propio puente) pasa a ser la única vía sensata. El dato técnico crítico es este: en Turquía, la factura e-Fatura/e-Arşiv (los sistemas turcos de factura electrónica) es un documento XML estructurado exigido por la GİB, la Administración Tributaria de Turquía. No hay OCR sobre un PDF o un escaneo: el documento se genera mediante programación y se transmite en segundos. Dicho de otro modo, la “integración de facturas” no es reconocimiento de imágenes, sino el trabajo de producir y analizar XML etiquetado. A continuación presentamos esta decisión no como un eslogan, sino mediante una matriz de decisión medible y el razonamiento del costo total de propiedad (TCO). Como empresa de software B2B y de marca blanca (white-label) con sede en Sakarya, que toma esta decisión constantemente para responsables de agencias y compradores corporativos, compartimos el marco exacto que utilizamos.

En este artículo, en lugar de un sermón genérico de “la integración es buena”, entramos en la mecánica: la realidad XML de la factura electrónica, qué hay que sincronizar realmente (stock, precios, pedidos, facturas y devoluciones), las ventajas e inconvenientes de un conector listo para usar, las ventajas e inconvenientes de un puente a medida, una matriz de decisión y, por último, el razonamiento de TCO “créditos frente a desarrollo + mantenimiento”. Ya tratamos el tema en un marco más amplio en nuestros artículos sobre software a medida frente a software estándar y ERP/CRM a medida para su empresa; aquí agregamos una capa específica del triángulo comercio electrónico + ERP + factura electrónica.

La realidad XML de la factura electrónica: aquí no hay OCR

La suposición errónea más común es concebir la integración de la factura electrónica como “escanear una factura e importarla al sistema”. En Turquía, la situación es distinta. Para e-Fatura y e-Arşiv, la GİB ha adoptado un estándar XML estructurado llamado UBL-TR; los documentos se preparan conforme a este paquete de esquemas (con codificación UTF-8). La integración por API significa que su software de pedidos, ventas o ERP se conecta a la GİB o al servicio web de un integrador privado y crea y envía la factura, además de hacer seguimiento de su estado, sin intervención humana. Como el documento es XML estructurado para máquinas de principio a fin, no hay ningún paso de OCR, ni al emitir ni al recibir una factura.

La consecuencia práctica es esta: el núcleo de la integración consiste en asignar campos como líneas de detalle, tasas impositivas, datos de la contraparte (comprador) y tipo de documento a los campos XML correctos. Según la definición oficial de la propia GİB, una e-Fatura puede emitirse por tres métodos: el Portal e-Fatura, la Integración (el sistema del propio contribuyente se conecta directamente, 24/7) y la Integración privada / Integrador privado. Un integrador privado sirve, en la redacción oficial de la GİB, para recibir y enviar facturas electrónicas en nombre del contribuyente “a través del sistema informático de un integrador privado con competencia técnica”; debe haber superado las pruebas de la GİB y contar con su aprobación (GİB: integración privada). En la práctica, un integrador privado asume la conexión con la GİB y la infraestructura y, por lo general, le ofrece una API REST. Esta distinción es también la base de su decisión de “conector listo para usar o puente a medida”; del lado de la API nos ocupamos en nuestro servicio de integraciones de API.

¿Qué hay que sincronizar realmente?

Un puente comercio electrónico ↔ ERP ↔ factura electrónica no es una única “transferencia de datos”, sino cinco flujos con ciclos de vida distintos. Sea cual sea la solución que elija, tiene que modelar los cinco:

  • Stock: Normalmente bidireccional. Un cambio de cantidad en el ERP debe reflejarse en el sitio, y una venta en el sitio debe reflejarse en el ERP. De lo contrario, seguirá vendiendo un producto que ya está agotado.
  • Precio y producto: En la mayoría de las configuraciones, la definición de precio y producto fluye del ERP al sitio; aquí los precios de campaña requieren especial atención.
  • Pedido: Fluye del sitio al ERP. El punto crítico: en la mayoría de los conectores, este flujo no es un envío en tiempo real, sino que funciona con polling intermitente, es decir, con consultas periódicas (detalles más abajo).
  • Factura: Conversión de pedido en factura. Aquí el documento e-Fatura, e-Arşiv o e-SMM (recibo electrónico de profesional independiente) se genera mediante programación y se registra formalmente en la GİB.
  • Devolución: El flujo que más a menudo se pasa por alto. No es posible “eliminar” una e-Fatura emitida; una devolución total o parcial se modela con un documento contable independiente (una factura de devolución).

Estos cinco flujos tienen requisitos distintos de latencia y coherencia. Por ejemplo, en la sincronización de pedidos, muchas integraciones con ERP funcionan con una lógica de lotes o polling: según la documentación de IdeaSoft y conectores similares, los pedidos que llegan del sitio se envían a Mikro ERP a través de una capa segura de servicios web a intervalos de aproximadamente 15 minutos (no mediante acceso directo a la base de datos), mientras que el stock, los productos y los precios se sincronizan en ambos sentidos (IdeaSoft: integración con Mikro). Estos ~15 minutos son un comportamiento de la aplicación conectora, no una garantía de la plataforma “Mikro”; además, “Mikro” abarca distintas líneas de producto (Jump, Fly y versiones anteriores) con superficies de integración diferentes. Debe tener en cuenta esta realidad del polling al planificar la latencia entre pedido y factura.

Idempotencia: el riesgo de ingeniería más traicionero del puente

Como la sincronización funciona por polling y los documentos e-Fatura y e-Arşiv se registran una sola vez en la GİB, un puente ingenuo puede emitir una factura duplicada ante un reintento o un webhook de pedido repetido. Eso significa duplicar un documento legal, algo problemático tanto para el cliente como desde el punto de vista fiscal. Un puente robusto requiere una clave de idempotencia por pedido, creación de facturas exactamente una vez (exactly-once) y una gestión cuidadosa de indicadores de estado como e_invoice_sent/e_archive_sent. Se trata de un requisito de ingeniería directo, derivado del modelo de documento registrado de la GİB y del comportamiento de polling observado. Abordamos este mismo rigor de webhooks e idempotencia en el lado del POS virtual en nuestra guía de integración de POS virtual; la misma disciplina se aplica al flujo de facturación.

Conector listo para usar: ventajas e inconvenientes

Los conectores listos para usar (como Entegra, Sopyo, Sentos e İkas) tienden un puente hacia sistemas ERP y de contabilidad básica (ön muhasebe), como Logo, Netsis, Mikro, Paraşüt y otros, y hacia el sistema de factura electrónica; pero su compatibilidad se articula en torno a una lista fija de plataformas de comercio electrónico, en su mayoría SaaS. Por ejemplo, Entegra conecta en ambos sentidos sistemas ERP como Logo, Netsis, Mikro, SAP, ETA, Zirve, DİA, Nebim, Paraşüt, Link y Microsoft Dynamics con plataformas de comercio electrónico como IdeaSoft, Ticimax, OpenCart, T-Soft, Hipotenüs, WooCommerce, Shopify, PrestaShop y Magento; ofrece pedido→factura con un clic, sincronización bidireccional de stock y precios y creación automática de contrapartes (Entegra: integración de comercio electrónico). De forma similar, Sopyo incluye plataformas como Shopify, WooCommerce, IdeaSoft, İkas y Ticimax junto con Logo, Mikro, Paraşüt y destinos de factura electrónica.

Ventajas Inconvenientes
Puesta en marcha rápida; pedido→factura, sincronización de stock y precios y creación automática de contrapartes sin programar. Solo admite plataformas con nombre incluidas en una lista; una tienda a medida o basada en código propio queda fuera del “camino feliz”.
La carga de mantenimiento recae en el proveedor, que asume los cambios de versión de la API y el cumplimiento con la GİB. Costo recurrente: suscripción + crédito por documento; crece a medida que crece el volumen.
Compatibilidad lista para usar con muchos destinos ERP y de factura electrónica; la carga de las pruebas no recae en usted. Personalización limitada; poca flexibilidad para reglas de negocio o asignaciones de campos propias.
Bajo costo de entrada para volúmenes pequeños o medianos y flujos estándar. Un pico de campaña o de Black Friday eleva directamente el consumo de créditos y el riesgo de volumen o de límites.

Esta es la verdadera brecha: estos conectores se dirigen a las plataformas con nombre, en su mayoría SaaS, y no incluyen compatibilidad con tiendas totalmente a medida o basadas en código propio. La página de integración de Sentos enumera solo plataformas concretas (İkas, Ticimax, Shopify, IdeaSoft, Hipotenüs, T-Soft, OpenCart, WooCommerce, Ethica) y no menciona software a medida o propietario (Sentos: integración B2C). Del mismo modo, las integraciones de İkas con contabilidad básica y ERP (Logo İşbaşı, Mikro, Nebim, Uyumsoft, Akınsoft Wolvox, DİA, Microsoft Dynamics, Netsis, Zirve, Link, las gratuitas BirFatura/Bizim Hesap, etc.) existen, pero existen porque İkas es en sí misma una plataforma SaaS alojada; la superficie de integración se sitúa entre la plataforma İkas y el ERP, de modo que una tienda a medida basada en código no puede reutilizarla sin migrar a İkas (İkas: integraciones de contabilidad básica).

Puente de API a medida: ventajas e inconvenientes

Un puente a medida es una capa escrita según sus reglas de negocio, en la que su sitio (o un servicio intermedio) llama directamente a las API del ERP y de un integrador privado o una plataforma contable. Las API de los sistemas modernos se prestan bien a ello. Por ejemplo, Paraşüt ofrece una API REST oficial (v4) que usa OAuth2 para la autenticación (host api.parasut.com, basePath /v4). La autorización pasa por los endpoints /oauth/authorize y /oauth/token; el access_token es de tipo Bearer, caduca en 2 horas y se renueva mediante un refresh_token. La especificación documenta tres tipos de concesión OAuth2: authorization_code, password y refresh_token; el URI de redirección predeterminado es urn:ietf:wg:oauth:2.0:oob (Paraşüt: documentación oficial de la API (swagger)).

Más importante aún, la API de Paraşüt expone los recursos de e-Fatura, e-Arşiv y e-SMM directamente: /{company_id}/e_invoices, /{company_id}/e_archives, endpoints .../pdf para el PDF y un enum documentado de estados de factura (printed, not_printed, invoices_not_sent, e_invoice_sent, e_archive_sent, e_smm_sent). Por tanto, para crear facturas y obtener el PDF mediante programación no hace falta ningún paso independiente de OCR o de documento. En el lado del ERP, Logo Netsis ofrece una API REST llamada “NetOpenX Rest” en su documentación oficial; esta API estandariza las funciones de NetOpenX para enviar datos al ERP y extraerlos de él en integraciones web y móviles sin romper la lógica de negocio (Logo: herramientas de personalización de Netsis). La existencia y el alcance funcional de esta API están verificados; aquí no afirmamos cuál es su mecanismo exacto de autenticación (token o sesión): basta con presentarla como una API REST con autenticación propia.

Ventajas Inconvenientes
Funciona con una tienda a medida o basada en código propio; no depende de una lista predefinida. Costo inicial de desarrollo + mantenimiento continuo (cambios de versión de la API, reintentos, desfase de sincronización).
Adaptación total a las reglas de negocio: la asignación de campos, la idempotencia y el flujo de devoluciones están bajo su control. Requiere una ingeniería correcta; no se puede descuidar la renovación de tokens de OAuth ni la gestión de errores y colas.
Usted diseña la arquitectura más allá de los créditos; no queda a merced de la dependencia de un proveedor. Debe seguir, con su propio calendario, los cambios de la GİB y normativos y los de las API de los integradores.
Una arquitectura predecible e independiente del volumen; el versionado y la observabilidad quedan en sus manos. Nota: los documentos de factura electrónica siguen pasando por un integrador privado o la GİB; la partida de créditos normalmente no desaparece.

Nota: un puente a medida no significa “librarse por completo de los créditos”; los documentos de factura electrónica siguen llegando a la GİB o al integrador privado, donde se consume un crédito por documento. Lo que le aporta un puente a medida es que la capa de orquestación y lógica de negocio le pertenece, sea cual sea su plataforma. Realizamos el trabajo de puentes a medida de forma conjunta en el ámbito del software web a medida y de las soluciones CRM/ERP.

Matriz de decisión: ¿cuándo basta un conector listo para usar y cuándo es imprescindible un puente a medida?

Para que la decisión sea intuitiva, estas son las reglas en una sola línea:

Situación Inclínese por Motivo
Tienda en una plataforma SaaS incluida en la lista del conector (WooCommerce, Shopify, İkas, Ticimax…) Conector listo para usar El “camino feliz” la cubre; la puesta en marcha es rápida y el mantenimiento recae en el proveedor.
Tienda totalmente a medida o basada en código propio, un desarrollo que no figura en ninguna lista Puente a medida Los conectores listos para usar no cubren esta tienda; usted llama directamente a la API del ERP o del integrador.
Flujo estándar, poca personalización, volumen medio Conector listo para usar Si no hay reglas propias, no hace falta un costo inicial de desarrollo.
Reglas de negocio propias (lógica de devoluciones particular, precios B2B, varias tiendas o varias contrapartes) Puente a medida La asignación de campos, la idempotencia y el flujo de facturas de devolución exigen control total.
Volumen muy alto o variable, acuerdo de nivel de servicio (SLA) estricto Normalmente a medida (o híbrido) La gestión de créditos y límites, junto con una arquitectura de colas y reintentos, exige previsibilidad.

La decisión no es “cuál es mejor”, sino “en qué casilla encaja su tienda”. Si está en una plataforma SaaS incluida en la lista, un conector listo para usar suele ser suficiente; si tiene una tienda a medida o basada en código propio, o reglas de negocio propias, un puente a medida no es una preferencia, sino una necesidad.

No subestime el flujo de devoluciones

Elija la vía que elija, tiene que modelar las devoluciones por separado. Como una factura e-Fatura o e-Arşiv emitida queda registrada en la GİB, no se puede simplemente “eliminar”: dentro de un breve plazo de cancelación, una factura e-Arşiv puede cancelarse y notificarse a la GİB, y una vez cerrado ese plazo, la corrección o devolución se hace con un documento de devolución (nota de crédito) (Paraşüt: cancelación de e-Arşiv frente a devolución). Tratar por separado las devoluciones totales y parciales es esencial para mantener la coherencia del stock, los saldos de las contrapartes y los registros fiscales. Aquí no damos el número de días del plazo de cancelación como regla firme, porque las fuentes difieren; si necesita una duración precisa, remítase al comunicado o la guía vigente de e-Arşiv de la GİB.

Razonamiento de TCO: ¿créditos o desarrollo + mantenimiento?

La decisión es, en realidad, una elección de forma de costo: un conector listo para usar es un gasto recurrente (suscripción + crédito por documento), mientras que un puente a medida es un gasto de desarrollo inicial + mantenimiento continuo. Las cifras son volátiles en 2026 y varían según el proveedor y el volumen; por eso, lea lo que sigue no como precios exactos, sino como rangos de mercado aproximados.

  • Crédito (un crédito digital por documento): Por lo general se gasta ~1 crédito por documento saliente (algunos proveedores también cobran por los entrantes). Según datos de comparación de mercado de 2026, el precio unitario del crédito en los principales proveedores ronda de media los 0,75–1,50 TL (liras turcas) por documento; en los integradores corporativos con integración ERP puede ser mayor por documento (se citan ~5–10 TL) (Faturaport: precios de créditos de 2026 (no es una lista oficial)). No son precios oficiales de los proveedores, sino una comparación de mercado con fecha.
  • Suscripción: La guía de costos de 2026 de Faturaport indica franjas de suscripción anuales (p. ej., solo factura electrónica: ~300–1500 TL/año; pymes: ~1500–6000 TL/año; grandes empresas: ~6000–50 000+ TL/año, según propuesta), y también hay costos recurrentes de certificados de sello fiscal/firma electrónica (Faturaport: guía de costos de la factura electrónica 2026 (no es una lista oficial)). Estas franjas también son aproximadas y dependen del proveedor.
  • Sensibilidad al volumen: Como los créditos y las suscripciones crecen con el volumen, un pico de campaña o de Black Friday eleva directamente el consumo de créditos y puede acercarle a los umbrales de volumen o de límite.

Un puente a medida cambia este modelo recurrente por desarrollo inicial + mantenimiento continuo: partidas como los cambios de versión de la API, la lógica de reintentos y colas y el desfase de sincronización generan costos con el tiempo. Su foco no debe ser memorizar el precio unitario, sino entender el mecanismo: si su volumen de documentos es grande y predecible, la partida recurrente de créditos puede acabar superando el costo de desarrollo inicial + mantenimiento; si su volumen es bajo o su plataforma ya es compatible, un conector listo para usar resulta mucho más económico. Evaluar el marco general junto con la lógica de nuestro artículo software a medida frente a software estándar aclara esta disyuntiva.

Cómo le ayuda Partnerfy

Como empresa de ingeniería de software B2B y de marca blanca con sede en Sakarya, tratamos esta decisión no como una “promesa”, sino como un proceso: primero diagnosticamos en qué casilla encaja su tienda (una plataforma SaaS incluida en la lista, un desarrollo a medida basado en código propio o una tienda con reglas de negocio propias), después trazamos el mapa de los cinco flujos (stock, precios, pedidos, facturas y devoluciones) y, por último, posicionamos correctamente un conector listo para usar o escribimos un puente de API a medida con la idempotencia y el flujo de devoluciones bien configurados. Para las agencias, entregamos este puente con su marca en un modelo de marca blanca; para los compradores corporativos, unimos sistemas de comercio electrónico y soluciones CRM/ERP en una sola línea observable.

Seamos sinceros: ningún puente puede garantizar que los créditos queden en cero ni que la normativa de la GİB nunca cambie; son variables externas. Nuestra promesa no es una garantía, sino una base: una arquitectura que emite cada factura exactamente una vez, modela las devoluciones con un documento independiente, no descuida la renovación de tokens ni los reintentos y soporta los picos de volumen. También atendemos los trabajos con base de código, reglas de negocio propias o una línea de ERP inesperada en el ámbito del software web a medida.

Conclusión

En un puente comercio electrónico ↔ ERP ↔ factura electrónica, la pregunta correcta no es “cuál es mejor”, sino “en qué casilla encaja mi tienda”. Si está en una plataforma SaaS incluida en la lista y sus flujos son estándar, un conector listo para usar suele ser suficiente, siempre que acepte la cuota recurrente de suscripción + créditos. Si tiene una tienda a medida o basada en código propio, o reglas de negocio propias, un puente de API a medida no es un lujo, sino una necesidad. En ambos casos, la factura electrónica no es un trabajo de OCR, sino de XML UBL-TR; modelar correctamente la idempotencia y el flujo de devoluciones no es negociable. Si tiene dudas sobre por dónde empezar, póngase en contacto con nosotros; clasificaremos su tienda y le prepararemos una decisión personalizada de “conector listo para usar o puente a medida” y una comparación de formas de costo.

Fuentes

Preguntas frecuentes

¿Debo elegir un conector listo para usar o un puente de API a medida para mi sitio de comercio electrónico?

La pregunta decisiva es el tipo de tienda. Si está en una plataforma SaaS incluida en la lista del conector, como WooCommerce, Shopify, İkas o Ticimax, y sus flujos son estándar, un conector listo para usar suele ser suficiente. Si tiene una tienda totalmente a medida o basada en código propio, o reglas de negocio propias (lógica de devoluciones particular, precios B2B), necesita un puente de API a medida, porque los conectores listos para usar no contemplan su caso.

¿Hay que leer la factura con OCR en la integración de la factura electrónica?

No. En Turquía, la factura e-Fatura/e-Arşiv es un documento XML estructurado en el estándar UBL-TR adoptado por la GİB, la Administración Tributaria de Turquía. El documento se genera mediante programación y se transmite a la GİB o a un integrador privado; no hay ningún paso de OCR ni de escaneo, ni al emitir ni al recibir una factura. El núcleo de la integración es asignar las líneas de detalle y los datos fiscales y de la contraparte a los campos XML correctos.

¿Qué hay que sincronizar exactamente en un puente?

Cinco flujos: stock (en su mayoría bidireccional), precio y producto (normalmente del ERP al sitio), pedido (del sitio al ERP, a menudo con polling de ~15 min), factura (pedido→e-Fatura/e-Arşiv, registrada en la GİB) y devolución (con un documento de devolución en lugar de eliminar la factura emitida). Cada flujo tiene un requisito distinto de latencia y coherencia; todos deben modelarse por separado.

¿Cómo se tramita una devolución sobre una factura electrónica ya emitida?

Como una factura e-Fatura o e-Arşiv emitida queda registrada en la GİB, no se puede eliminar sin más. Dentro de un breve plazo de cancelación, una factura e-Arşiv puede cancelarse y notificarse a la GİB; cerrado ese plazo, la corrección o devolución se hace con un documento de devolución (nota de crédito) independiente. Las devoluciones totales y parciales deben tratarse por separado para que el stock, los saldos de las contrapartes y los registros fiscales sigan siendo coherentes. Para conocer el plazo exacto de cancelación, remítase a la guía vigente de e-Arşiv de la GİB.

¿Un puente a medida me libra del costo de los créditos?

Normalmente no. Los documentos de factura electrónica siguen llegando a la GİB o al integrador privado, donde se consume un crédito por documento; en la mayoría de los casos, un puente a medida no elimina esta partida. Lo que le aporta un puente a medida es que la capa de orquestación y lógica de negocio le pertenece. La decisión es una elección de forma de costo: ¿suscripción recurrente + créditos (listo para usar) o desarrollo inicial + mantenimiento (a medida)?

¿Por qué se prefiere a la mejor empresa de software en Sakarya para integrar el comercio electrónico con el ERP y la factura electrónica?

Partnerfy, empresa de ingeniería de software B2B y de marca blanca con sede en Adapazarı (Sakarya) y oficinas en Turquía, Alemania, Rusia e Irlanda, gestiona este trabajo no como una promesa, sino como un proceso: primero clasifica su tienda (plataforma SaaS incluida en la lista o desarrollo a medida basado en código propio), traza el mapa de los cinco flujos (stock, precios, pedidos, facturas y devoluciones) y después posiciona correctamente un conector listo para usar o escribe un puente de API a medida con la idempotencia y el flujo de devoluciones bien configurados. Sin vender estadísticas inventadas ni garantías, y construyendo una base medible que emite cada factura exactamente una vez, figura entre las empresas de software preferidas en Sakarya.