Cómo unificar el reporting financiero de tus razones sociales desde SAP

Si tu grupo opera con varias razones sociales sobre SAP, conocés el ritual del cierre de mes: cada sociedad exporta su balance, alguien arma un Excel maestro, se pegan los saldos, se convierten las monedas a mano con el tipo de cambio del día que alguien recuerde, se cruzan las operaciones entre empresas del grupo… y recién ahí aparece un número consolidado. Que para cuando está listo, ya es viejo.

El problema no es SAP. SAP hace exactamente lo que fue diseñado para hacer: registrar la contabilidad de cada sociedad con rigor. El problema es que SAP no fue pensado para consolidar automáticamente varias razones sociales, con distintos planes de cuentas y monedas, en una sola vista de grupo. Y forzarlo a ese rol termina en planillas interminables, cierres de dos semanas y decisiones tomadas con datos de hace un mes.

La solución es extraer los datos de SAP y llevarlos a un lugar diseñado para consolidar y analizar. En esta guía te mostramos exactamente cómo lo hacemos.

Qué significa realmente "unificar razones sociales"

En SAP, cada razón social es una sociedad (company code, el campo BUKRS). Y ahí empiezan las diferencias que hacen que consolidar a mano sea tan doloroso:

Cada sociedad puede tener su propio plan de cuentas local. La cuenta "Ingresos por ventas" puede ser 410000 en una razón social y 700001 en otra. Si no las mapeás a una estructura común, no hay forma de sumar la facturación del grupo.
Cada sociedad puede operar en su propia moneda. Para tener un número de grupo necesitás convertir todo a una moneda única, con un tipo de cambio consistente para todas.
Hay operaciones entre empresas del grupo (intercompañía). Si la sociedad A le factura a la B, ese ingreso no es ingreso del grupo: hay que identificarlo y eliminarlo, o el consolidado queda inflado.

Unificar razones sociales es resolver estas tres cosas de forma automática y repetible: un mismo plan de cuentas de grupo, una misma moneda, y la intercompañía marcada — para que el consolidado salga solo, todos los meses, sin Excel.

La arquitectura completa: de SAP al tablero

Antes de entrar en los pasos, este es el panorama de lo que construimos:

SAP FI/CO → Extracción (SLT / OData / CDS) → Google Cloud Storage (crudo) → BigQuery (data warehouse) → dbt (mapeo + conversión + consolidación) → Power BI (tableros)

Parece mucho, pero cada pieza tiene un rol claro y, una vez montado, funciona solo. Vamos parte por parte.

Paso 1: Entender qué datos tiene SAP

Toda la información financiera de tus sociedades vive en tablas que se pueden consultar de forma directa. Las relevantes para consolidar son:

Transaccionales (los números):

ACDOCA — el Universal Journal de S/4HANA. Una sola tabla con FI y CO. Campos clave: RBUKRS (sociedad), RACCT (cuenta), RYEAR/POPER (ejercicio/período), HSL (importe en moneda local), RASSC (sociedad GL / partner intercompañía).
BKPF + BSEG — cabecera y posiciones de documento contable (en ECC, o para el detalle).
FAGLFLEXA — partidas del ledger nuevo (New GL en ECC).

Maestros (el contexto y las claves de unificación):

T001 — las razones sociales: sociedad, nombre, plan de cuentas (KTOPL) y moneda local (WAERS).
SKA1 / SKAT — maestro de cuentas y sus textos.
T004 — los planes de cuentas.
T011 — las Financial Statement Versions (la jerarquía de P&L y Balance para reportar).
TCURR — los tipos de cambio.

⚠️

Toda la extracción es de solo lectura. Nunca se modifican tablas del SAP productivo. Trabajar contra SAP siempre debe ser SELECT / lectura vía CDS u OData — modificar datos rompe la integridad del sistema contable.

Paso 2: Extraer los datos de SAP

La extracción se puede hacer de varias formas, según tu paisaje SAP:

Vistas CDS / OData — la vía nativa en S/4HANA. Se exponen los datos como servicios y se leen de forma incremental.
SAP SLT o SAP Datasphere — replicación gestionada, útil si ya tenés esas herramientas licenciadas.
Google Cloud Cortex Framework — el acelerador de Google para llevar datos de SAP a BigQuery con modelos predefinidos.
Agente propio — un extractor liviano en Python que corre incremental y sube a la nube, cuando se busca control total y bajo costo.

En todos los casos, se extrae de forma incremental (solo lo nuevo o modificado desde la última corrida) y programada — típicamente de madrugada.

ℹ️

La extracción no toca la aplicación SAP ni consume licencias de usuario de diálogo. Se conecta a la capa de datos (CDS/OData o replicación) con un usuario técnico de solo lectura. No interfiere con la operación diaria.

Paso 3: Guardar el crudo en la nube (Data Lake)

Los datos aterrizan primero en Google Cloud Storage, organizados por fecha y por sociedad. Es tu "backup inteligente": aunque SAP siga operando normal, tenés una copia histórica, versionada y consultable de tus datos contables. Si algún día necesitás ver cómo estaba el balance de una razón social hace seis meses, está ahí.

El costo de almacenamiento para un grupo típico es de centavos por mes.

Paso 4: Cargar en BigQuery (Data Warehouse)

Desde Cloud Storage, los datos se cargan a BigQuery tal cual salieron de SAP: mismos nombres de campo, mismos códigos, mismas monedas. Todavía no es fácil de analizar, pero ya está en un lugar donde podemos trabajarlo — sin tocar SAP y sin frenar la operación.

BigQuery
└── grupo_raw
    ├── raw_acdoca        (asientos: sociedad, cuenta, período, importe)
    ├── raw_t001          (razones sociales)
    ├── raw_ska1_skat     (plan de cuentas + textos)
    ├── raw_t011          (financial statement versions)
    └── raw_tcurr         (tipos de cambio)

Paso 5: Unificar en dbt (el paso clave)

Acá el dato crudo se convierte en un consolidado real. dbt transforma con SQL puro, con tests y documentación. Las tres transformaciones que resuelven la unificación de razones sociales son:

Mapeo de cuentas → cada cuenta local se traduce a una línea del plan de cuentas de grupo (la Financial Statement Version de T011). Así 410000 de una sociedad y 700001 de otra suman en la misma línea "Ingresos".
Conversión de moneda → los importes locales (HSL) se convierten a la moneda de grupo con el tipo de cambio de TCURR, usando un mismo tipo de cotización para todas las sociedades.
Intercompañía → se identifican las operaciones entre empresas del grupo por el trading partner (RASSC) para poder marcarlas o eliminarlas.

En SQL, la lógica central se ve así (simplificada):

-- Consolidar ACDOCA de todas las sociedades a moneda de grupo
select
    acd.rbukrs                        as sociedad,
    t001.butxt                        as razon_social,
    map.linea_grupo                   as linea_fs,        -- cuenta local → FSV de grupo
    acd.ryear,
    acd.poper                         as periodo,
    sum(acd.hsl)                      as importe_local,
    sum(acd.hsl * fx.ukurs)           as importe_grupo    -- conversión con TCURR
from acdoca            acd
join t001             t001 on t001.bukrs  = acd.rbukrs
join mapeo_cuentas    map  on map.ktopl   = t001.ktopl
                          and map.cuenta  = acd.racct
join tcurr            fx   on fx.fcurr    = t001.waers
                          and fx.tcurr    = 'USD'         -- moneda de grupo
                          and fx.kurst    = 'M'           -- tipo de cotización
group by 1, 2, 3, 4, 5

El resultado son tablas limpias y auditables, listas para reportar: un modelo de P&L y Balance de grupo, con la sociedad y el documento original siempre trazables.

💡

La ventaja de hacerlo en dbt es que el mapeo de cuentas y las reglas de conversión quedan versionados, documentados y testeados. Si una línea del P&L no cuadra contra el cierre de SAP, hay un test que lo detecta. Es la diferencia entre una planilla frágil y un sistema que finanzas puede auditar.

ℹ️

En S/4HANA, ACDOCA ya guarda un importe en moneda de grupo (KSL). Aun así, la consolidación suele necesitar un tipo de cambio único y uniforme para todas las sociedades y un mapeo a la FSV de grupo — por eso el modelo en dbt sigue siendo necesario.

Paso 6: Visualizar en Power BI (Tableros)

Con el dato consolidado en BigQuery, los tableros son la parte más rápida. Un solo modelo de Power BI conectado a BigQuery, con drill-down de grupo → razón social → documento. Los tableros que armamos como base:

Estado de Resultados consolidado: ingresos, margen bruto, EBITDA y resultado neto — de grupo y por razón social, real vs presupuesto.
Balance: activo, pasivo y patrimonio por sociedad y consolidado; capital de trabajo y deuda neta.
AR / AP y Caja: aging de cuentas por cobrar y pagar, DSO/DPO, posición de caja por sociedad y moneda.
Intercompañía y FX: saldos entre empresas del grupo, exposición cambiaria y ajuste por conversión.
Ejecutivo: consolidado en moneda de grupo, mix de contribución por razón social, margen por entidad, crecimiento interanual.

Cada tablero se actualiza solo con cada extracción. Finanzas abre un link y ve el consolidado del grupo — sin pedirle a nadie que "arme el Excel".

Cuánto cuesta

Costos mensuales de infraestructura para un grupo típico:

Google Cloud Storage: menos de USD 1/mes
BigQuery: entre USD 10 y USD 40/mes según volumen y consultas
Power BI: licencia Pro, alrededor de USD 10-14 por usuario/mes
Extracción SAP: depende del método — con CDS/OData nativo el costo es bajo; con SLT o Datasphere puede apoyarse en licencias SAP que ya tengas

Total de infraestructura: en el orden de USD 30-80 por mes para un grupo mediano. El desarrollo e implementación es aparte y de única vez; una vez montado, el pipeline corre solo.

Cuánto tarda la implementación

Para un grupo con varias razones sociales sobre SAP:

Semana 1: Relevar sociedades (T001), planes de cuentas y definir la FSV de grupo objetivo
Semana 2: Extracción de SAP (ACDOCA + maestros) → GCS → BigQuery
Semana 3: Mapeo de cuentas locales → grupo y conversión de monedas (TCURR) en dbt
Semana 4: Reglas de intercompañía y validación — cuadrar el consolidado contra el cierre real de SAP
Semanas 5-6: Tableros en Power BI y ajustes con el equipo de finanzas

La parte que más cuida el tiempo no es la técnica, es el cuadre: que el número que sale del pipeline coincida al centavo con el cierre contable. Cuando eso valida, finanzas confía en el tablero.

¿Y si tengo ECC en vez de S/4HANA?

La arquitectura es la misma. Lo que cambia son las tablas de origen: en lugar de ACDOCA, se extrae de BKPF + BSEG y FAGLFLEXA (New GL) o GLT0 (GL clásico). El resto del pipeline — GCS, BigQuery, el mapeo en dbt, los tableros — es idéntico.

Y si tu grupo tiene un paisaje mixto (algunas sociedades en SAP, otras en otro ERP, o alguna todavía en Excel), también sirve: cada fuente entra por su propio extractor y todas confluyen en el mismo modelo de grupo. La unificación de razones sociales no depende de que todas estén en el mismo sistema.

Conclusión

Tener el consolidado del grupo atrapado en un cierre manual de dos semanas es como manejar mirando por el espejo retrovisor: ves dónde estuviste, no dónde estás.

Unificar el reporting financiero de tus razones sociales desde SAP no es un proyecto de innovación. Es infraestructura básica que todo grupo con varias sociedades debería tener: un consolidado que sale solo, en una moneda, con las cuentas alineadas y la intercompañía resuelta — todos los meses, sin Excel.

El costo es bajo, la implementación es de semanas, y el impacto se nota desde el primer cierre que finanzas hace en horas en lugar de días.

En Richmond Analytics diseñamos y construimos esta arquitectura para grupos con múltiples razones sociales. Si querés ver el consolidado de tu grupo en tableros que se actualizan solos, hablemos.