WorldwideTradeX es una empresa comercial con sede en Estambul: suministramos, exportamos y entregamos.

Volver a Desarrollo de software a medida y arquitectura ERP para B2B
Factura electrónica de Türkiye: integración con el ERP - Especificaciones Técnicas

Factura electrónica de Türkiye: integración con el ERP

Para operar en Türkiye, un software ERP suele tener que soportar e-Fatura y e-Arşiv, y e-İrsaliye en algunos sectores, a través de la Administración Tributaria (GİB), normalmente mediante un integrador privado. El ERP crea el documento en formato UBL-TR, el vendedor lo firma con el sello financiero (mali mühür), el integrador lo valida ante el GİB y el contribuyente sigue siendo responsable de la conservación en todo momento.

¿Qué debe soportar un ERP para operar en Türkiye?

Türkiye gestiona la facturación electrónica como un sistema de validación previa: un documento lo crea el vendedor, se transmite por un canal autorizado, la Administración Tributaria lo valida y solo entonces tiene efectos legales. Para una empresa que opera sobre un ERP, esto tiene consecuencias en cuatro puntos del sistema:

  • Creación del documento. El ERP —o un motor conectado— debe generar las facturas en la estructura UBL-TR exigida, con los códigos, los identificadores de las partes y los datos de línea que pide el esquema; no basta con reconvertir una maqueta impresa a XML.

  • Firma digital. Los documentos se firman con el sello financiero (mali mühür) expedido al contribuyente; el paso de firma tiene que estar dentro del flujo, con una gestión de claves acorde con las condiciones de custodia del sello.

  • Intercambio bidireccional. En el régimen de e-Fatura, el estado de registro de la contraparte decide el tipo de documento, y los documentos entrantes —facturas recibidas, respuestas, anulaciones donde se permiten— deben volver al ERP con sus identificadores originales, o la contabilidad pierde el vínculo entre el sistema y el registro oficial.

  • Archivo y recuperación. Los documentos emitidos y recibidos deben poder recuperarse durante el plazo de conservación legal; que los guarde el integrador, que los guarde el ERP o que los guarden los dos es una decisión que se toma antes de la puesta en marcha y no después de una solicitud de auditoría.
La mayoría de las empresas cumplen esto no reconstruyendo su ERP, sino conectándolo: una capa de integración entre el ERP y un integrador privado, con el ERP como sistema de registro de clientes, artículos, precios y contabilidad.

Un punto estructural que sorprende a los equipos que se estrenan en los sistemas de validación: la factura no termina cuando el ERP la imprime. Termina cuando el intercambio se completa y vuelven las respuestas, lo que significa que la noción que tiene el ERP del estado de una factura tiene que ir más allá de «creada» y «enviada» para incluir aceptada, rechazada y corregida. Los negocios que se saltan esto acaban conciliando a mano, al final del mes, dos versiones de la verdad —su libro mayor y el registro oficial—, que es exactamente el trabajo que la facturación electrónica debía eliminar.

Otro punto es el de los tiempos. Los documentos de un sistema de validación no son asíncronos al estilo de un adjunto de correo: un rechazo llega mientras el equipo sigue trabajando, y la corrección que pide suele tocar los datos maestros y no el propio documento. Diseñar el flujo de modo que la persona que puede arreglar la causa reciba el aviso en ese momento, en lugar de descubrirlo en un informe mensual, es la diferencia entre un sistema que funciona y un sistema que hay que vigilar.

e-Fatura, e-Arşiv e-İrsaliye explicados

DocumentoSe usa paraDisparador habitualNota
e-FaturaFacturas B2B y de empresa a administración entre contribuyentes registrados en el régimenLas dos partes están registradas en e-FaturaDocumento estructurado intercambiado entre partes registradas; el estado de la contraparte decide la vía
e-ArşivFacturas en las que el comprador no está registrado en e-Fatura: comercio minorista y B2C, y parte del B2BEl vendedor está en el ámbito; el comprador queda fuera del régimen de e-FaturaSe entrega al comprador como PDF, pero se genera y se declara a través de la misma cadena
e-İrsaliyeAlbaranes electrónicos para los sectores y las operaciones designados por las normasEnvío de mercancía dentro de los flujos cubiertosSe acopla a la factura: el albarán y la factura se referencian mutuamente
e-DefterLibros y registros: libro mayor y libro diario, declarados electrónicamenteContribuyentes en el ámbito, según las normas aplicablesObligación separada de la factura electrónica, pero que suele planificarse en el mismo proyecto

Quién queda bajo cada obligación lo definen las normas y las circulares del GİB, que cambian; los umbrales y las designaciones de sector los fijan las autoridades y cambian con ellas. La formulación correcta para un comprador es de tipo procedimental: compruebe su estado de registro con su contable o asesor fiscal contra las normas vigentes antes de diseñar la integración, y no contra un artículo, ni siquiera este.

Opciones de integración con el ERP

OpciónEncajeEsfuerzo en el ERPPrecauciones
Portal del GİBVolúmenes muy pequeños, emisión manualNinguno en el ERPManual y lento; no es un objetivo de diseño para una empresa con ERP, así que consérvelo solo como recurso de emergencia
Integrador privado (özel entegratör)La vía habitual para la mayoría de las empresasUna conexión a la API o al formato del integrador, más el mapeoComparar integradores por soporte y calidad de la API importa más que por el logo; pregunte quién mantiene las actualizaciones del esquema
Acceso directo al GİBOperaciones mayores que quieren control totalAlto: usted asume la responsabilidad técnica y operativa del canalMás complejo de obtener y de operar; se describe como raro en la práctica, de modo que trátelo como una excepción que justificar y no como algo por defecto

El modelo de integrador merece una aclaración, porque se entiende mal: usar un integrador privado no transfiere las obligaciones del contribuyente. El integrador aporta el canal técnico, la transmisión y el servicio de almacenamiento; la responsabilidad legal de los documentos —su corrección, su emisión y su conservación conforme a la Ley de Procedimiento Tributario— sigue siendo del contribuyente. Cuando la página comercial de un integrador suena a que el problema de cumplimiento se queda resuelto, vuelva a leer esa frase.

En la práctica, esta división aparece en formas pequeñas y concretas. Si un documento se rechaza porque el identificador fiscal del cliente estaba mal en sus datos maestros, el sistema del integrador funcionó perfectamente y el error es suyo para arreglarlo. Si una factura se emite con el código impositivo equivocado, ninguna comprobación del canal le salvará. El integrador es infraestructura; la calidad de los datos que fluyen por ella es una disciplina interna, y el ERP es el sitio donde esa disciplina se incorpora o se deja a la costumbre. Los compradores que comparan integradores deberían dedicar menos tiempo a la lista de funciones y más a las preguntas que revelan quién hace qué cuando algo falla: quién avisa a quién, en qué formato y a qué velocidad puede retransmitirse un documento corregido.

Pasos de implantación y pruebas del ERP

Una secuencia viable para una integración por el lado del ERP:

  1. Fije el ámbito de las obligaciones. Qué documentos corresponden al negocio —e-Fatura, e-Arşiv, e-İrsaliye, e-Defter—, confirmados con el contable de la empresa contra las normas vigentes.

  2. Elija el canal. La mayoría de las empresas selecciona un integrador privado; las preguntas de selección —calidad de la API, disponibilidad de entorno de pruebas, idioma y horario del soporte, gestión de actualizaciones del esquema, referencias— merecen su propio ejercicio de lista corta.

  3. Mapee los datos maestros. Clientes y sus identificadores fiscales, artículos, unidades, monedas y códigos impositivos deben mapearse con lo que espera el esquema; las discrepancias aquí son la mayor fuente individual de errores posteriores.

  4. Diseñe el flujo del documento. Quién crea qué, cuándo se aplica el sello, qué ocurre en caso de fallo, cómo se concilian los documentos salientes y entrantes con los registros del ERP y cómo se emiten las correcciones.

  5. Use el entorno de pruebas. Las dos partes ofrecen un entorno de pruebas; ejecute en él todo tipo de documento, todo camino de error y todo escenario de corrección antes de la puesta en marcha, con el mismo mapeo que se usará en producción.

  6. Trate el error como un proceso. Los rechazos llegan después de la transmisión; alguien tiene que verlos, entender la causa y corregir el dato de origen. Una bandeja de avisos sin responsable es la manera en que un negocio termina emitiendo documentos tarde.

  7. Planifique el archivo y el acceso. Dónde se guardan los documentos, quién puede recuperarlos y cómo se contesta a una solicitud del auditor dentro del plazo de conservación.
La parte que decide el éxito no es la interfaz: son los pasos 3, 6 y 7 —calidad de los datos, responsabilidad del error y recuperación—, porque continúan cuando el equipo del proyecto se ha ido a casa.

Puntos que debe llevar a un asesor: matriz extranjera y no residente

Para una empresa con matriz extranjera, o que entra en Türkiye sin un equipo financiero local completo, varias preguntas corresponden al asesor fiscal y no al proyecto de TI: las respuestas determinan el diseño, así que hágaslas antes de que empiece la integración y no después:

  • Vía de registro. Cómo queda la empresa sujeta a las obligaciones, quién firma las solicitudes y qué representante se reconoce: cuestiones de registro fiscal, no de software.

  • Sello. Cómo se obtiene el sello financiero para la empresa y cómo se organiza su custodia cuando los firmantes están fuera de Türkiye.

  • Representantes y firmas. Quién está autorizado a firmar cada tipo de documento y qué debe registrar el ERP sobre el firmante para el rastro de auditoría.

  • Situación de la filial. Si se aplican requisitos adicionales a las empresas con titularidad no residente y cómo se tratan las facturas dentro del grupo.
Estas preguntas se formulan deliberadamente como cuestiones para un asesor: las normas de registro y de representación cambian, son locales y una página de producto no puede calificarlas. Lo que el proyecto de TI sí puede hacer es diseñarse para que las respuestas sean lentas: mantenga el flujo de documentos configurable y no codificado en torno a una sola hipótesis.

También compensa decidir quién es dueño de la relación con el asesor. En empresas donde finanzas y TI dan por hecho que el otro ya ha hecho la pregunta, estos puntos llegan tarde a la integración, normalmente en las semanas previas a la puesta en marcha, cuando el flujo del documento ya está fijado. Un responsable con nombre en cada lado y una reunión conjunta antes del paso 3 de la implantación evitan la mayor parte de esos problemas.

Incidencias frecuentes

Las fallas que más se repiten en este tipo de proyecto y a qué suelen apuntar:

  • Rechazos en la validación. Casi siempre un problema de mapeo: un código impositivo, un formato de identificador o un campo de línea que no coincide con lo que espera el esquema. Arregle los datos maestros, no la lógica de reintentos.

  • Numeración duplicada. Secuencias de numeración generadas por más de un sistema, o regeneradas tras un fallo; la numeración debe tener exactamente un responsable y una regla de recuperación documentada.

  • Errores en el estado de la contraparte. Emitir el tipo de documento equivocado porque el estado de registro del cliente estaba en caché o se dio por supuesto: consulte el estado según las reglas del integrador y no según la memoria.

  • Documentos entrantes perdidos. Documentos recibidos que nunca se contabilizan de vuelta en el ERP, de modo que la cuenta por pagar trabaja desde otra pantalla; la dirección del intercambio forma parte de la integración y no es un extra opcional.

  • Actualizaciones de esquema perdidas. La estructura cambia con el tiempo; quien sea responsable debe saber cuándo cambió y qué hizo ese cambio en el mapeo.

  • Pruebas saltadas por presión de fecha. Todo lo anterior sale más barato en el entorno de pruebas; la presión de la puesta en marcha es donde se convierte en incidentes.

Preguntas frecuentes

¿Cuál es la diferencia entre e-Fatura y e-Arşiv?

e-Fatura cubre las facturas intercambiadas entre contribuyentes registrados en el régimen, como documentos estructurados entre partes registradas; e-Arşiv cubre las facturas en las que el comprador queda fuera de ese régimen —comercio minorista y B2C, y parte del B2B—, y que el comprador recibe por lo general como un PDF generado a través de la misma cadena oficial. Cuál de los dos corresponde a una factura determinada se deduce del estado de registro de la contraparte, y por eso la integración lo comprueba en lugar de darlo por supuesto.

¿Necesito un integrador privado?

Para la mayoría de las empresas, sí: es la vía habitual, y el canal directo se describe como complejo y raro. Un integrador privado aporta el canal técnico hacia el GİB y el servicio de almacenamiento; sus obligaciones como contribuyente siguen siendo suyas. Elegirlo es un ejercicio de compras: la calidad de la API, el entorno de pruebas, el soporte y la gestión de las actualizaciones del esquema deciden la experiencia diaria más que la marca.

¿Qué es el sello financiero (mali mühür)?

Es la credencial de firma digital del contribuyente que se usa para firmar los documentos electrónicos antes de transmitirlos; la custodia y quién puede usarlo son cuestiones prácticas que se resuelven dentro de la empresa. Para los equipos con firmantes fuera de Türkiye, el acuerdo sobre quién conserva y quién aplica el sello es uno de los primeros puntos que hay que poner delante de un asesor fiscal.

¿Puede cualquier ERP emitir facturas electrónicas turcas?

No. El ERP debe generar la estructura UBL-TR exigida con los datos maestros correctos, o estar conectado a un motor o a un integrador que lo haga; una maqueta de factura estándar no basta. Por eso la mayoría de las empresas conecta en lugar de reconstruir: la pregunta que hay que hacer a un proveedor es qué integradores soporta su conector, qué mapea y dónde está su documentación.

¿Cómo pruebo antes de la puesta en marcha?

A través de los entornos de pruebas que ofrecen tanto el integrador como la parte oficial, usando el mismo mapeo de datos maestros que en producción: todo tipo de documento, todo camino de rechazo, toda corrección y cada documento entrante contabilizado de vuelta en el ERP. Trate la prueba como un ensayo del proceso de error: alguien debe recibir, diagnosticar y arreglar un rechazo, no solo ver una palomita verde.

¿Quién guarda las facturas?

El contribuyente sigue siendo responsable de la conservación conforme a la Ley de Procedimiento Tributario; el integrador suele aportar el almacenamiento técnico, y muchas empresas además guardan los documentos en su ERP para el uso diario. Lo importante es decidir el arreglo antes de la puesta en marcha, saber quién puede aportar qué documento dentro del plazo de conservación y probar esa recuperación antes de que un auditor la pida.

Fuentes y estándares

  • GİB — Gelir İdaresi Başkanlığı — la Administración Tributaria publica las normas, las circulares y la documentación técnica de e-Fatura, e-Arşiv, e-İrsaliye y e-Defter; las versiones vigentes allí prevalecen sobre todo lo resumido en esta página.
  • El estado de registro, los umbrales, las designaciones de sector y los plazos los fijan las autoridades y cambian; confirme con su contable o asesor fiscal contra las normas vigentes. Nada de esta página es asesoramiento fiscal, y no se afirma ninguna relación de integrador, alianza o certificación para WorldwideTradeX.

Páginas relacionadas

Desarrollo de software · Odoo ERP para empresas de comercio · ERP a medida frente a estándar · Auditoría y consultoría de TI · Solicitar presupuesto

Temas relacionados

Portal de pedidos B2B con software ERP para distribuidores → Externalización de software en Türkiye: selección de proveedor → Odoo ERP para empresas de comercio: guía de implantación → Lista de comprobación RFP para proveedores de software →