Bramvia — Business Central Experts

Business Central en Latinoamérica: qué cubre Microsoft, qué necesita localización de partner y dónde entramos nosotros

México tiene localización nativa de Microsoft (CFDI 4.0, Carta Porte); el resto de Latinoamérica depende de localizaciones de partners. Qué significa eso para tu proyecto, cómo se combina una localización local con desarrollo y migración, y qué hacemos —y qué no— desde España.

Respuesta corta: Business Central está disponible en más de 170 países, pero la localización fiscal no es igual en todos. En Latinoamérica, México tiene funcionalidad local de Microsoft (CFDI 4.0, complemento de pago, Carta Porte, contabilidad electrónica, DIOT); el resto de países —Argentina, Colombia, Chile, Perú, Panamá, Paraguay, Venezuela, Ecuador, Costa Rica, Guatemala, República Dominicana— funcionan con localizaciones desarrolladas por partners especializados (AlfaPeople, LLB Solutions y otros), publicadas en AppSource. Esa distinción decide tu proyecto: la localización la pone un especialista local; todo lo demás —migración desde el sistema antiguo, desarrollo AL, integraciones, Power BI, agentes de IA, rescate de proyectos— es independiente del país. Ahí es donde trabajamos nosotros, desde España, en español. Y un matiz que suele sorprender: en México el software de facturación no necesita certificación del SAT —quien la necesita es el PAC que timbra—, así que la integración fiscal sí puede desarrollarse cuando el proyecto lo justifica. En otros países el esquema de habilitación varía y se verifica antes de prometer nada.

El mapa fiscal, sin rodeos

Cuatro esquemas XML distintos para cuatro países: lo que vale para la DIAN no vale para el SAT, y lo que cubre el SII chileno no cubre a SUNAT. Un ERP, varias localizaciones — y todas pueden convivir en un mismo tenant cuando la arquitectura se diseña bien (una ventaja real para grupos con presencia regional).

¿Hace falta que el software esté certificado?

Esta es la pregunta que decide si una localización se puede desarrollar o no, y la respuesta no es la misma en todos los países.

En México, no. El sistema de facturación no necesita autorización del SAT. Quien la necesita es el PAC (Proveedor Autorizado de Certificación), la empresa que valida, timbra y envía el CFDI a la autoridad. El flujo es: tu ERP genera el XML → lo envía por API al PAC que elija tu empresa → el PAC valida, incorpora el Timbre Fiscal Digital con su UUID y lo remite al SAT. El contribuyente solo necesita e.firma vigente, Certificado de Sello Digital y un PAC contratado. Eso significa que la integración fiscal sí se puede desarrollar — es el mismo patrón que ya aplicamos con el SII español: generar, validar antes de enviar, transmitir por API e interpretar la respuesta.

En otros países, depende. Colombia (DIAN), Chile (SII) y Perú (SUNAT) tienen esquemas propios en los que el emisor —y en algunos casos el proveedor tecnológico— pasa por un proceso de habilitación. Antes de comprometer nada, verificamos el país concreto: es lo primero que hacemos en la evaluación.

Qué hacemos y qué no

Lo que no hacemos: no vendemos una localización fiscal latinoamericana "de catálogo", ni timbramos comprobantes (el timbrado lo hace siempre un PAC autorizado, en México y su equivalente en cada país). Y no adaptamos la localización española a otro país: quien te ofrezca eso te está vendiendo un problema con fecha.

Lo que sí hacemos:

• Migración desde el sistema anterior: Dynamics NAV/Navision, ERP local, desarrollos a medida o Excel. La guía completa del método: inventario de objetos, conversión C/AL → AL, datos validados contra el sistema vivo, arranque por fases.
• Desarrollo AL de extensiones limpias que sobreviven a las dos actualizaciones anuales — y que conviven con la localización local sin tocarla.
• Integración fiscal a medida cuando el proyecto lo justifica: si la localización disponible no cubre un caso concreto (un complemento, un flujo de cancelación, una retención específica), lo desarrollamos como extensión conectada al PAC o al proveedor tecnológico del país. Es exactamente lo que hemos hecho en España con el SII, Cartera, Confirming e Intrastat, y lo que hacemos ahora con el DeCA.
• Integraciones: tienda online, WMS, EDI, bancos, CRM, por API y OData.
• Power BI y reporting, incluida la vista consolidada de grupos multipaís.
• Agentes de IA sobre procesos concretos, con gobernanza.
• Rescate de proyectos atascados y segunda opinión independiente.
• Capacidad de desarrollo para partners locales: si eres un partner en México, Colombia o Perú con más trabajo que desarrolladores AL, trabajamos en marca blanca sobre tu proyecto.

Una advertencia honesta sobre las localizaciones: una localización fiscal no se desarrolla, se mantiene. El SAT actualizó catálogos de CFDI 4.0 en 2026 y publica cambios de complementos con regularidad; lo mismo ocurre en el resto de países. Por eso no construimos localizaciones "por si acaso": las construimos cuando hay un cliente concreto detrás y un acuerdo de mantenimiento que las sostiene en el tiempo. Lo contrario —vender una localización y dejarla envejecer— es el problema que luego nos llaman a rescatar.

Cómo se monta un proyecto regional bien

1. La localización, de un especialista del país. Se contrata su app de AppSource y su acompañamiento fiscal. Es su terreno y hacen bien en defenderlo.
2. El núcleo del proyecto, con quien tenga el método. Procesos, migración de datos, desarrollo, integraciones y reporting no cambian por país.
3. Un solo tenant cuando hay varias sociedades, con intercompañía y consolidación, y cada sociedad con su localización. Es lo que evita el clásico "un ERP por país" que luego nadie consolida.
4. Todo por partes, con criterios de aceptación escritos y pago solo tras aceptar cada parte. A distancia, esa cláusula importa más todavía.

Por qué desde España tiene sentido (y cuándo no)

Sí tiene sentido cuando el proyecto pesa en desarrollo, migración o rescate: mismo idioma, horario que solapa con la mañana latinoamericana (España va 6-8 horas por delante de México y 5-6 de Argentina — lo entregado por la tarde española está listo al empezar el día allí), y tarifas europeas por debajo de las de un especialista escaso local.

No tiene sentido si lo que necesitas es exclusivamente cumplimiento fiscal local y acompañamiento presencial continuo. Ahí el partner de tu país es la respuesta correcta, y te lo diremos.

Preguntas frecuentes

¿Podéis implantar Business Central en México? Sí: migración, desarrollo, integraciones y reporting, sobre la localización mexicana nativa de Microsoft y el PAC que elijas. Si tu caso necesita algo que la localización no cubre, lo desarrollamos como extensión conectada al PAC. El asesoramiento fiscal ante el SAT lo lleva tu asesor: nosotros construimos el sistema que lo ejecuta.

¿Y en Colombia, Perú o Argentina? Igual, con la localización de partner correspondiente instalada desde AppSource, y con la verificación previa del esquema de habilitación de cada país (DIAN, SUNAT, AFIP) antes de comprometer alcance.

¿Podéis desarrollar una localización fiscal desde cero? Podemos, y en España lo hemos hecho (SII, Cartera, Confirming, Intrastat, DeCA). Pero solo con un cliente concreto detrás y un acuerdo de mantenimiento: una localización exige seguir cada cambio normativo indefinidamente. Sin ese compromiso, es mejor usar una localización existente del ecosistema.

¿Trabajáis con partners locales? Sí, y es nuestro modelo preferido en la región: ellos ponen localización y cercanía, nosotros capacidad técnica en AL, migración y datos.

¿Qué pasa con el soporte y el huso horario? Solapamos con la mañana latinoamericana. Para incidencias urgentes se acuerda una ventana de respuesta por escrito en el contrato.

¿Cómo empezamos sin riesgo? Con una parte pequeña: una evaluación del sistema actual, un informe que nadie ha construido, una integración atascada. Se paga después de aceptarla.

¿Operas en Latinoamérica y necesitas capacidad técnica en Business Central? Evaluación gratuita y sin compromiso — en español, y con respuesta en 1 día laborable.

Bramvia · bramvia.net