Tally Fixed Asset Reconciliation — Matching Your Register to Your Books
Published: April 14, 2026
The fixed asset register says the organisation has assets worth Rs 2.4 crore. Tally says Rs 2.35 crore. The difference is Rs 5 lakh. Nobody knows where it comes from.
This is not unusual. In most Indian organisations, the fixed asset register and the accounting books are maintained separately — the asset register tracks what was bought, where it is, and what condition it is in, while Tally tracks the financial entries: purchase vouchers, depreciation journals, and write-off entries. Over time, these two records drift apart. A purchase is entered in Tally but the asset is not added to the register. An asset is scrapped in the register but the write-off entry is not posted to Tally. A reversal is processed in one system but not the other.
Reconciliation is the process of comparing these two records, identifying differences, and resolving them. This article explains how structured reconciliation works when the asset management system and Tally are connected, what causes drift, and how to prevent it.
1. Why the Numbers Drift Apart
Even in organisations that use both an asset management system and Tally, drift happens for predictable reasons:
- Manual Tally entries. The accountant enters a purchase voucher directly in Tally because the GRN has not been processed yet. The asset is capitalised in the books but does not exist in the asset register.
- Silent sync failures. The system generates a Tally XML voucher and sends it, but Tally was offline or the company was in a different financial year. The system marks the item as "sent" but Tally never received it.
- Timing differences. An asset posted in the register on 31 March but the Tally voucher created on 1 April ends up in different financial years.
- Partial reversals. A GRN is reversed in the asset system (which removes the asset from the register), but the corresponding reversal voucher in Tally fails or is skipped.
- Rounding. GST calculations in the asset system use one rounding method; Tally uses another. The difference is typically a few rupees per transaction, but across hundreds of transactions, it accumulates.
- Ledger mapping changes. The asset classification "IT Equipment" maps to Tally ledger "Computers" — but someone renames the Tally ledger to "IT Equipment (Fixed)" without updating the mapping. New vouchers fail, but old ones remain under the old ledger name.
2. The Three Dimensions of Reconciliation
Effective reconciliation compares the asset system and Tally across three dimensions:
2.1 Voucher Count Matching
The simplest check: does the number of vouchers match? For each event type — purchase posting, depreciation journal, write-off entry, vendor debit note — count the items in the asset system marked as POSTED and count the corresponding vouchers in Tally.
| Event Type | Asset System (POSTED) | Tally (Vouchers) | Difference |
|---|---|---|---|
| Purchase Voucher | 142 | 140 | 2 missing in Tally |
| Depreciation Journal | 12 | 12 | Match |
| Write-Off Entry | 8 | 7 | 1 missing in Tally |
| Vendor Debit Note | 5 | 5 | Match |
A count mismatch is the clearest signal. If the asset system shows 142 purchase postings but Tally has only 140 purchase vouchers, exactly 2 items need to be found and resolved.
2.2 Vendor Ledger Balance Comparison
Beyond counts, compare the total amounts posted per vendor. For each vendor, sum all posted amounts in the asset system and compare against the vendor's ledger balance in Tally.
Vendor-level comparison catches a category of errors that count matching cannot: a voucher exists in both systems but with a different amount (perhaps due to a manual correction in Tally), or two vouchers exist in Tally for the same transaction (double entry).
2.3 Asset Class Ledger Balance Comparison
The third dimension compares by asset classification. Total capitalised value for "Furniture" in the asset system should match the "Furniture" ledger balance in Tally. Total capitalised value for "IT Equipment" should match the corresponding Tally ledger.
Asset class comparison reveals ledger mapping issues — if the asset system maps "Laboratory Equipment" to Tally ledger "Lab Equipment" but some items were manually posted to "Scientific Instruments" in Tally, the class-level totals will not match even though the overall total might.
3. Verification — Checking Individual Items
Reconciliation works with aggregates. Verification works with individual items. For each item marked as POSTED in the asset system, verification checks whether the corresponding voucher actually exists in Tally.
This catches a specific failure mode: phantom postings. The asset system records a successful sync, but the voucher does not exist in Tally — perhaps because Tally was restarted during the XML import, or the voucher was manually deleted in Tally.
Reconciliation tells you the totals do not match. Verification tells you exactly which items are missing. Both are needed — reconciliation for the big picture, verification for the specific exceptions.
4. The Queue — How Sync Failures Are Handled
When the asset system generates a Tally voucher, the voucher does not go directly to Tally. It enters a queue with a status lifecycle:
| Status | Meaning |
|---|---|
| PENDING | Voucher generated, waiting to be sent |
| PROCESSING | Currently being sent to Tally |
| POSTED | Tally accepted the voucher |
| FAILED | Tally rejected or was unreachable — will be retried |
| SKIPPED | Manually skipped by admin (e.g., duplicate, test entry) |
Failed items are retried automatically. Items that exhaust all retries move to a dead letter queue — a holding area for items that need manual investigation. Common dead letter causes:
- Ledger does not exist in Tally. The mapping references a ledger that was deleted or renamed in Tally.
- Financial year mismatch. Tally's active financial year does not match the voucher date.
- Company mismatch. The Tally company was switched or the connection points to a different company.
- Tally server persistently offline. The desktop Tally instance was shut down and nobody restarted it.
The dead letter queue preserves the full voucher XML so the item can be retried once the underlying issue is fixed, or manually entered if necessary.
5. Pre-Processing Validation
The most effective way to prevent reconciliation issues is to catch them before posting. Pre-processing validation checks all PENDING items against live Tally state before any vouchers are sent:
- Ledger existence check: Does every ledger referenced in the pending vouchers exist in Tally? If "Computer Equipment" is referenced but Tally only has "Computers," the mismatch is flagged before posting.
- Missing ledger resolution: The system can suggest which Tally ledgers are close matches (fuzzy matching) and can even auto-create missing ledgers in Tally if configured to do so.
- Connection health: Is Tally online and responsive? Is the correct company loaded?
Running pre-processing validation before each sync batch eliminates the most common failure causes and keeps the dead letter queue empty.
6. Practical Reconciliation Workflow
- Weekly: Check the sync queue for FAILED and dead letter items. Resolve before they accumulate.
- Monthly: Run the full reconciliation report — voucher counts, vendor balances, asset class balances. Investigate any differences.
- Before year-end: Run verification on all POSTED items. Confirm every item in the asset system has a matching voucher in Tally. Resolve all dead letter items.
- After year-end: Run reconciliation one final time after books are closed. The numbers should match. If they do not, the specific discrepancies from the reconciliation report tell you exactly where to look.
7. Recent Updates — Reversed Vouchers and Foreign-Currency Assets
Two structural changes to the underlying Tally integration materially affect how reconciliation reads. They are summarised below.
7.1 Reconciling Reversed Vouchers
Reversals are now paired to their forwards via Tally's "Agst Ref" field — the original voucher number is stored on the reversal's bill reference. In the Outstandings report this surfaces the pair under the same reference. A reversed asset acquisition therefore shows up in the asset register reconciliation as two paired entries with net-zero effect on Tally's fixed-asset group — exactly the reconciliation behaviour that the previous ISOPTIONAL reversal pattern obscured. See Tally integration guide — reversals for the underlying mechanism.
7.2 Foreign-Currency Assets and Forex Revaluation
For assets acquired from foreign vendors, the original purchase voucher posts against a foreign-currency vendor ledger. Tally handles the forex revaluation and settlement gain / loss internally — the asset side of the entry is booked in the reporting currency at the GRN-locked rate. When you reconcile the asset register to Tally, the asset value matches the Fixed Asset group at booked-rate; the currency exposure shows on the vendor ledger and on Tally's forex revaluation entries. Reconciliation comparisons should therefore be made on the asset ledger group (INR-only) rather than the vendor ledger group, which legitimately carries forex movements not reflected in the asset register.
8. Frequently Asked Questions
Why do Tally and the fixed asset register show different numbers?
The most common cause is that entries are made in one system but not the other. A purchase voucher may be entered in Tally directly without going through the procurement workflow, or a GRN may be posted in the asset system but the Tally sync failed silently. Other causes include timing differences, manual Tally entries that bypass the integration, reversed transactions where only one system was updated, and rounding differences in GST calculations. Reconciliation identifies these gaps so they can be investigated and corrected.
How does automated reconciliation work between EAM and Tally?
The reconciliation process compares three dimensions: voucher counts (how many purchase vouchers, journal entries, and debit notes exist in each system), vendor ledger balances (total amounts posted per vendor), and asset class ledger balances (total capitalised value per asset classification). Differences are flagged with the specific item, amount, and direction of mismatch. The reconciliation reads live Tally data via the Tally XML API and compares it against the posted items in the asset management system.
What is the difference between reconciliation and verification of posted items?
Reconciliation compares aggregate totals — does the total in the asset system match the total in Tally? Verification checks individual items — for each item marked as POSTED in the asset system, does the corresponding voucher actually exist in Tally? An item may be marked POSTED because the sync appeared to succeed, but the voucher might not exist in Tally due to a network failure or a manual deletion. Verification catches these phantom postings that reconciliation totals might miss.
How often should reconciliation be performed?
Monthly reconciliation is the practical minimum for organisations actively procuring assets. This catches drift early — a mismatch accumulated over one month is easier to investigate than one accumulated over twelve. Some organisations run reconciliation weekly during high-procurement periods. Year-end reconciliation is mandatory before closing books, but by that point, mismatches are harder to investigate because transactions are months old.
What happens when a Tally sync fails?
Failed sync items enter a queue-based retry system. Each item is attempted multiple times with the failure reason recorded. Items that exhaust all retries move to a dead letter queue where they can be investigated manually. Common causes include Tally being offline, ledger not existing in Tally, or financial year mismatch. The dead letter queue preserves the full voucher data so the item can be retried or manually entered once the issue is resolved.