Faster Tally Reporting. No Complex Keys Required!
We consolidate SAP ECC, Tally and Excel into one reconciled SQL Server reporting layer - no migration, no new licenses, no change to your source systems.
Most mid-size Indian groups do not run one system. SAP ECC holds the plant and corporate books. Tally holds the branch, trading or statutory books. Excel holds the budget and the adjustments nobody wants to talk about.
So month-end becomes an assembly job. Someone exports from SAP. Someone else exports from Tally. The two are merged in a workbook, and finance still asks why the vendor balance is different in each. Ten days later there is a consolidated P&L, and the questions start again.
The data already exists on day one. The problem is that it lives in three places that do not agree on what a vendor, an account or an entity is.
That is what a data warehouse fixes.
SAP is built to run transactions, not to answer questions. Reporting directly out of ECC means SE16 exports, ABAP requests that sit in a queue, and reports that slow the production system when they run over a full year of MSEG or BSAK.
A warehouse sits beside SAP and takes the reporting load off it.
You stop querying the production system. Extracts run on a schedule through read-only RFC function modules. Nobody runs a year-end report against live ECC again.
History stops being a licensing question. SAP archiving and retention policies are decided by cost. Warehouse history is decided by you. Five years of purchase and material movement data sits in SQL Server, queryable in seconds.
Reports stop needing a developer. Once MSEG, MKPF, EKKO, EKPO, BSIK and BSAK are staged and modelled into dimensions and facts, a report change is a Power BI edit, not an ABAP request and a transport.
The technical field names disappear. LIFNR becomes vendor. MATNR becomes item. WERKS becomes plant. Finance can build their own views without learning SAP's table structure.
Your data outlives your support contract. Mainstream maintenance for ECC ends in 2027. Whatever you decide about S/4HANA - move, delay, or stay - the reporting layer is already outside SAP and unaffected by that decision. If you migrate later, the warehouse switches its source connector and every downstream report keeps working.
A SAP-only warehouse gives you clean reports with holes in them. The group P&L still needs the Tally entities. So the Excel merge survives, and so does the argument at month-end.
The mismatch between SAP and Tally is usually not a systems problem. Both systems are correct within their own books. It is a mapping problem:
Two charts of accounts that were never reconciled to each other
The same vendor sitting in SAP as a code and in Tally as a ledger name, spelled slightly differently
Company codes in SAP and company names in Tally with no shared entity key
Different fiscal conventions and different levels of account detail
We resolve this in the warehouse, not in your systems.
Read from both, change neither. SAP is read through read-only RFC function modules. Tally is read through its own built-in XML gateway on port 9000 - no TDL customisation is installed on your Tally. Where the Tally machine is not reachable over the network, scheduled XML or Excel exports into a watched folder feed the same tables.
Land everything in one place. Both sources go into a staging layer, then into an operational data store where fields carry business names instead of technical ones.
Map the identities. A conformance layer answers one question for every row: which single entity, account, party or item does this belong to, whichever system it came from. The mappings live in tables - MAP_ENTITY, MAP_ACCOUNT, MAP_PARTY, MAP_ITEM - that a functional consultant maintains. Not code. Initial mapping is proposed automatically by exact code and normalised name matching; a human approves it.
Design one chart of accounts. Every SAP G/L account and every Tally ledger points at a node in a unified chart of accounts built from your existing reporting formats. Each node is tagged P&L, balance sheet, cash flow or COGS - so every statement is a view of one fact table, not four separately built reports.
Prove it ties out. Every load captures each system's own trial balance and compares it to warehouse totals per entity and period. Within tolerance, the dashboards refresh. Outside tolerance, the dashboards hold their last good state and an alert names the variance by account.
That last point matters more than the rest. A consolidated number that cannot be traced back to the trial balance of the system it came from will not be signed off. It should not be.
What comes out of it
Consolidated P&L, balance sheet and cash flow across all entities, SAP and Tally together
COGS, optionally reconciled against material movement quantities
Receivables and payables ageing on a single party master, so one vendor is one vendor
Budget versus actual, with budgets and manual adjustments loaded from validated Excel templates
Purchase and material movement analysis across plants and periods
A mapping exception report - unmapped rows always load and are always visible, so nothing is silently dropped
Delivered through Power BI, SSRS or Excel. You keep whichever BI tool you already have.
Not a migration. SAP stays where it is, on the version it is on. So does Tally.
Not a new licence. No SAP BW, no SAP Analytics Cloud, no Tally add-on. The warehouse runs on SQL Server you likely already own.
Not a change to how anyone works. Nothing is installed on user machines. Accounts teams keep posting in the same systems, the same way. Read access is read-only in both directions.
Not a replacement for your ERP decision. If you move to S/4HANA in three years, the warehouse changes one connector.
A read-only RFC communication user in SAP and gateway access, plus the transport for the extraction function modules
Tally's gateway enabled, or a scheduled export to a shared folder
Your current reporting formats - the P&L and balance sheet you actually circulate today. These define the chart of accounts, which is why we ask for them early
A named person on the finance side who can confirm account mappings
That last one is usually the constraint, not the technology.
The first step is a 20-minute Reporting Health Check: which systems, which entities, which formats, and where the current month-end actually loses its days. No deck. If it is useful after that, the chart-of-accounts workshop is a short paid engagement that produces the mapping design - and de-risks everything built afterwards.
Your SAP data will outlive your SAP support. We set it free - no migration, no licenses, no disruption.
Write to us and we'll set up the 20 minutes.
Does anything get installed on SAP?
A transport containing read-only function modules. No change to standard SAP objects, no impact on postings.
Will extracts slow down our production system?
They run on a schedule, usually overnight, and pull incrementally by document date after the first full load. Reporting queries then hit SQL Server, not SAP - so the long-running report extracts that load your production system stop running against it.
We are on ECC and staying past 2027. Does that rule us out?
It is the opposite. Staying is a defensible decision, and it is the case where an external reporting layer is worth most.
Does this work with S/4HANA?
Yes. On RISE or Private Edition the same RFC path works with a network route. On Public Edition, OData APIs feed the identical staging tables - the warehouse and every report downstream are unchanged.
What about Navision, Dynamics NAV or other systems?
Technically simpler than SAP, since they sit on SQL Server already. Additional sources follow the same connector pattern and are scoped separately.
How long does it take?
The SAP extraction layer is the fastest part. A full SAP + Tally consolidation with statement marts is a phased build, typically three to four months, with usable output well before the end.