Tally Migration Toolkit

The problem

Across South Asia and the Gulf, the system SAP Business One usually replaces is Tally. The business has outgrown it — multiple locations, real inventory control, manufacturing, approval workflows, a group structure, or an investor who wants auditable process — but the entire financial history and every master record lives in Tally.

Tally's data model does not line up with SAP Business One's. Tally uses a single tree of ledgers under groups, where a customer, a supplier, a bank account and an expense head are all ledgers distinguished only by the group they sit under. SAP Business One splits that into Business Partners with control accounts and a segmented chart of accounts across five drawers. Tally stock items carry units, alternate units and godown-wise balances; SAP B1 wants Items with UoM groups and warehouse rows. GST masters — GSTIN by party, HSN and SAC codes, place of supply, tax rate structures — have to arrive intact or the first GSTR filing after cutover is a problem.

And the export format is XML. Tally XML is exportable and complete, but it is nested, tag-heavy, and built around Tally's own naming — it is not something a generic import wizard consumes usefully.

What ECOSIRE builds

This is a build-to-order toolkit. Nothing is pre-built and there is nothing to download. After a scoping call we build a migration engine against your Tally XML exports and your target SAP Business One company database, install it, and run it with you.

Tally XML parsing and staging

We build a parser for the Tally XML envelope structure covering masters (LEDGER, GROUP, STOCKITEM, STOCKGROUP, GODOWN, UNIT, VOUCHERTYPE) and vouchers, and land the parsed output into User-Defined Tables (UDTs) inside the SAP B1 company database, untransformed. Every SAP Business One record created carries its Tally master name or voucher number in a User-Defined Field (UDF), so any record can be traced back to the exact Tally entry it came from — which matters when the accounts team asks why a balance looks unfamiliar.

Ledger and group conversion

The hardest judgement in a Tally migration is deciding what each ledger becomes. We classify ledgers by their Tally group: Sundry Debtors become customer Business Partners, Sundry Creditors become vendor Business Partners, and the remainder become general ledger accounts placed into SAP Business One's five-drawer segmented ChartOfAccounts. That classification is not hidden in code — it is held in a UDO-backed mapping form your accountant reviews and adjusts, because only they know which ledgers under 'Current Assets' are genuinely balance-sheet accounts and which are a party in disguise.

GST and tax masters

GSTIN, PAN, party type (registered, composition, unregistered, SEZ) and place of supply are migrated onto Business Partner master data and their addresses, so the correct intra-state versus inter-state tax determination applies on the first document raised. HSN and SAC codes migrate onto Items. Tally tax ledgers and rate structures map explicitly to SAP Business One tax codes and tax groups — CGST, SGST, IGST and cess — with the mapping agreed with your accountant before build, not inferred afterwards. Where reverse charge applies, the flag is carried to the Business Partner and item level.

Stock items and godowns

Tally stock items become SAP Business One Items with stock groups mapped to item groups, base and alternate units mapped to UoM groups with the conversion factor preserved, and Tally godowns mapped to SAP B1 Warehouses. Godown-wise closing balances load per warehouse via InventoryPostings, respecting the valuation method configured in SAP Business One — moving average, standard or FIFO. Batch numbers with manufacturing and expiry dates, and serial numbers where used, migrate with their attributes. Bin locations are supported where bin management is enabled.

Opening balances and open transactions

Ledger closing balances at the cutover date are posted as balanced JournalEntries, with debtors and creditors routed through control accounts so subsidiary ledgers agree with the general ledger. Bill-wise details — Tally's per-bill outstanding tracking — become open A/R Invoices, A/R Credit Memos, A/P Invoices and A/P Credit Memos at their remaining balance, carrying original bill number and date in UDFs so the receivables and payables ageing in SAP Business One matches the Tally outstanding statement your team already trusts. On-account receipts and payments come across as unapplied payments. Open sales and purchase orders are migrated with pending quantities where you track them in Tally.

Multi-currency and multi-company

Foreign-currency ledgers carry document currency, local-currency amount and the rate applied. Where you run several Tally companies for one business — a common pattern — we scope the target as one SAP Business One company database per legal entity unless consolidation is required, and the mapping layer keeps each source company traceable.

Reconciliation proof

Each run produces a reconciliation pack, delivered as Crystal Reports inside SAP Business One: object counts and totals comparing source to target, a trial-balance comparison against the Tally trial balance at cutover, receivables and payables ageing versus the Tally outstanding statement, stock quantity and value per warehouse against godown summary, and an exception list naming every record that did not convert and why.

Who it is for

Businesses in India, Bangladesh, Sri Lanka, the UAE, Saudi Arabia and the wider Gulf moving from Tally ERP 9 or TallyPrime to SAP Business One 10.0 — typically distributors, manufacturers and multi-branch traders where inventory and tax compliance are the pressure points, and where the accounts team will not re-key years of masters by hand.

Technical basis

Built as a SAP Business One add-on using the Service Layer (REST/OData) for bulk object creation, the DI API where an object or field is not exposed through the Service Layer, and UDT/UDF/UDO extensibility for XML staging, mapping and traceability. Compatible with SAP Business One 10.0 on Microsoft SQL Server and SAP HANA, on-premise or cloud-hosted. Delivered per tenant, installed into your test company database first and into production only once reconciliation is signed off. Where your target configuration uses approval procedures and Crystal Reports layouts, the migration is built to respect them.

How delivery works

1. Scoping call — we look at your real Tally XML exports, ledger and group counts, godown structure, GST registrations, currency use and how many Tally companies are in scope. You receive a written mapping document, including the ledger-classification decisions. 2. Fixed quote — fixed price and delivery date against that scope. 3. Build — typical lead time one working week depending on ledger and stock-item volume and the number of Tally companies. 4. Install in test — installed into your test company database, full trial migration, reconciliation pack handed to your accountant and stock controller. 5. Iterate — reclassifying ledgers and re-running is expected and included. Raw XML stays in staging, so a re-run is a reload rather than a rebuild. 6. Production cutover — final run at the agreed cutover date into the production company database, reconciliation signed off before users are given access. 7. Support window — an included post-go-live period so anything found during your first GST filing period and first close is fixed by the team that built it.