Running Tally Alongside Export Operations Software
Tally handles your books. It was never designed to hold a production pipeline, a destination-specific document set or a RODTEP claim. Here is how the two layers divide sensibly.
Almost every Indian export business we meet runs Tally, and almost none of them wants to stop. That is the right instinct — Tally is accounting software, it does accounting well, and your accountant and auditor already work in it. The question is not whether to replace it but what should sit alongside it.
Tally was designed as an accounting system. An export order, before it ever becomes an accounting entry, is a production schedule, a document set, a compliance decision and a scheme claim. Those are operational objects, and asking an accounting package to hold them is asking it to do something it was not built for.
This page sets out a sensible division of responsibility between the two layers, and what to expect practically when both are in use.
The problem
Where the accounting-only approach strains
Production has no home
An order in production is not yet an accounting event, so its status lives in a spreadsheet or someone's memory.
Export documents are typed separately
Invoices, packing lists and declarations are prepared in Word or Excel templates rather than generated from the order.
Scheme claims sit outside the books
RODTEP, ROSCTL and Drawback receivables are tracked on the side, which is how claims get missed.
Per-order cost is assembled by hand
Sampling, transport, job-work and CHA charges are recorded but not attached to the order they belong to.
The solution
What sits in the operations layer
Order and production tracking
Every order's real stage, from confirmation through production to dispatch.
Document generation
Nine export document types produced as PDFs from the order record itself.
Buyer and destination requirements
Destination-specific certificate and wording requirements stored against the buyer.
Per-order costing
Overheads including sampling, transport, majoori and CHA attached to the order that incurred them.
Incentive claim tracking
Scheme eligibility and claim status followed per order through to credit.
Multi-currency invoicing
Export invoices across 22 currencies using DGFT-published rates.
How it works
How the two layers divide
Operations runs the order
Enquiry, order, production, documents and dispatch are handled in the operations layer.
Accounting records the transaction
Invoices and payments are recorded in Tally, which remains the book of record for statutory purposes.
Claims close the loop
Incentive claims are tracked operationally against each order and reconciled once credited.
Why an accounting package cannot hold export operations
The distinction is about when information exists rather than about capability. An accounting system records transactions — events that have happened and have a financial value. Most of an export order's life consists of things that have not happened yet and have no financial value.
An order in sampling has no accounting entry. An order awaiting buyer approval has no accounting entry. An order half-produced has no accounting entry. Yet these states are exactly what an export business needs visibility over, because they are where delivery dates are won or lost.
The same applies to documentation. A commercial invoice has an accounting dimension, but a packing list, a certificate of origin and an export value declaration do not — they are operational documents that happen to accompany a financial one. Preparing them separately is how the mismatches that trigger customs queries arise.
None of this is a criticism of Tally. It is a statement about what accounting software is for. Asking it to hold production stages and destination-specific document rules would make it worse at the thing it is genuinely good at.
What a sensible division looks like in practice
The clearest boundary is the transaction. Anything that is a financial event with statutory consequence belongs in the accounting layer — sales invoices, purchase entries, payments, receipts, tax filings. Anything that describes the state or the paperwork of an order belongs in the operations layer.
Under that split, the operations layer becomes the place where an order lives from enquiry to claim, and the accounting layer becomes the place where its financial consequences are recorded. The invoice is the natural handover point, because it is the first artefact that is unambiguously both.
This also resolves the question of which system is authoritative. For anything an auditor will look at, Tally is the book of record and nothing changes about that. For anything about where an order is, what documents it carries and whether its claim has been filed, the operations layer is authoritative — because those facts do not exist in the books at all.
Businesses that get into difficulty are usually those that left the boundary undefined, so that order status is tracked in three places and nobody is certain which is current.
What to expect when you introduce an operations layer
The first thing most businesses notice is that documentation preparation compresses sharply. Work that involved locating weights, confirming addresses and retyping buyer details becomes generation from data already captured, and the document set stops contradicting itself.
The second is that per-order profitability becomes real rather than approximate. Costs that were previously recorded as general expenses — sampling, transport, job-work charges, CHA fees — get attached to the order that incurred them, and the margin figure stops being an estimate.
The third, and the one businesses tend to underestimate, is that scheme claims stop leaking. When claim status is a property of the order rather than a periodic review exercise, a shipped and eligible but unclaimed order becomes visible immediately instead of being discovered after the window has closed.
What does not change is your accounting practice. Your accountant continues working in Tally, the audit trail continues to run through it, and statutory filings are unaffected. The operations layer sits before that, not on top of it.
Data movement between the layers
The practical question everyone asks next is how data moves between the two. The honest answer is that it depends on how your business is set up, and that the volume involved is smaller than people expect.
The information that genuinely needs to cross is invoice-level: sales invoices raised operationally need to appear in the books, and payment status recorded in the books is useful operationally. Ledger detail, journal entries and statutory workings have no operational counterpart and do not need to move at all.
ExportCRM supports Excel export of invoice and purchase data, which covers the common requirement of periodic entry into the books without a live connection. Many businesses find this sufficient, because the accounting entry is a periodic activity rather than a real-time one.
TODO(owner): if you want this page to describe a direct Tally connector or a specific import format, supply the confirmed capability and we will state it precisely. It is deliberately not claimed here, because the page should not describe an integration mechanism that has not been verified.
One thing worth settling early is who performs the accounting entry and when. Where a bookkeeper enters invoices weekly, an Excel handover fits that rhythm naturally and nobody needs to change how they work. Where invoices are entered daily by the same person raising them, the handover is better placed at the point the invoice is issued, so the two records never drift apart by more than a single document.
Frequently asked questions
Does ExportCRM replace Tally?
No, and it is not designed to. Tally is accounting software and remains your book of record for statutory purposes — your accountant and auditor continue working in it exactly as before. ExportCRM sits in front of that as an operations layer, holding the order from enquiry through production, documentation and dispatch to the incentive claim. The invoice is the natural handover point between the two.
Why can't Tally handle export operations on its own?
Because accounting systems record transactions — events that have happened and carry a financial value — while most of an export order's life consists of states that have no accounting entry at all. An order in sampling, awaiting buyer approval or half-produced is invisible to the books, yet those states are exactly where delivery dates are decided. Operational documents such as packing lists and certificates of origin similarly have no financial dimension.
How should work divide between Tally and an export operations system?
Use the transaction as the boundary. Financial events with statutory consequence — sales invoices, purchase entries, payments, receipts, tax filings — belong in Tally. Anything describing the state or paperwork of an order — production stage, document set, destination requirements, per-order costs, scheme claim status — belongs in the operations layer. This also settles which system is authoritative for any given question.
Can invoice data move from ExportCRM into Tally?
ExportCRM supports Excel export of invoice and purchase data, which covers the common pattern of periodic entry into the books rather than a live connection. In practice the volume that genuinely needs to cross is small — invoice-level information rather than ledger detail, journals or statutory workings, none of which have an operational counterpart. For a specific connector or import format, ask us to confirm current capability rather than assuming it.
Will introducing an operations layer disrupt our accounting?
It should not. Your accounting practice, audit trail and statutory filings continue unchanged, because the operations layer sits before the books rather than on top of them. What changes is upstream: document preparation compresses because documents are generated from order data, per-order costing becomes real as overheads attach to the orders that incurred them, and scheme claims stop leaking because claim status becomes a property of the order.
Keep Tally. Add the operations layer.
Book a free demo and see how order tracking, export documentation and incentive claims work alongside the books you already keep.