How to Import Invoices into TallyPrime

TallyPrime gives you three native paths to import invoice and purchase voucher data, each suited to a different workflow:

• Excel (.xlsx) — Best for one-time imports and ad hoc uploads where you need to get a batch of invoices into Tally quickly without building reusable automation.
• XML — Suited for automated workflows and multi-voucher batch imports. XML supports reusable mapping templates, making it the go-to format for recurring import jobs.
• JSON — Added in TallyPrime 7.0, JSON is ideal for API-driven integrations and developer-built pipelines that push data directly into Tally from external systems.

The format you choose shapes every downstream step, from how you structure your data to how you handle errors. This guide focuses specifically on purchase voucher import, the most common invoice import scenario for AP teams and bookkeepers working in TallyPrime. Whether you're importing a quarter's worth of supplier invoices before a GST filing deadline or migrating historical data from another system, purchase vouchers are where the bulk of the work lands.

Most guides on how to import invoices into TallyPrime assume you already have clean, structured data sitting in a spreadsheet. In practice, supplier invoices arrive as PDFs, scanned copies, WhatsApp images, or email attachments. The real workflow challenge often starts before the import step, when you need to turn those unstructured documents into data TallyPrime can actually consume.

---

Excel, XML, or JSON: Choosing the Right Import Format

TallyPrime accepts invoice data in three formats, each suited to a different workflow. The right choice depends on how often you import, how complex your vouchers are, and what your upstream data source produces.

Excel is the most familiar option and works well for one-off or ad hoc imports. You prepare your data in a spreadsheet, then use TallyPrime's Import Data feature to map columns to voucher fields. For simple imports, this is the fastest path from data to ledger. The limitation surfaces with multi-line purchase vouchers: a single invoice with several line items requires careful row structuring where header fields (supplier name, invoice number, date) repeat across every row belonging to that voucher. There is no built-in automation either. Each import is a manual trigger.

XML is TallyPrime's longest-supported structured format and the better choice for regular or bulk imports. A single XML file can contain hundreds of purchase vouchers, each with its own header and nested line items in one node. No row repetition tricks, no flattening required. XML also works with reusable mapping templates, so once you define the structure, subsequent imports follow the same configuration without rework. Most third-party Excel-to-Tally converter tools generate XML for exactly this reason. The trade-off is that building XML files from scratch requires familiarity with Tally's XML schema, or a converter tool that handles it for you.

JSON is the newest addition, supported from TallyPrime 7.0 onward. If your upstream system already produces JSON output, which is common with modern extraction tools, API-based workflows, and developer-built pipelines, importing directly avoids an unnecessary conversion step. JSON is also more human-readable than XML, making it easier to inspect and debug before import. The practical downside: JSON support in the Tally ecosystem is still relatively new, so community documentation, forum threads, and third-party tool support are thinner compared to XML.

If you are unsure which format to use, start with Excel for your first import to understand how TallyPrime's field mapping works, then move to XML or JSON as your volume or automation needs grow.

Purchase Voucher Fields TallyPrime Expects

Before you build your import file, you need an exact map of what TallyPrime requires for each purchase voucher. Missing a single mandatory field or misspelling a ledger name will reject the entire row, and GST-specific fields carry their own set of traps. This section gives you the complete field reference so you can structure your Excel, CSV, or XML correctly on the first attempt.

Mandatory Fields for Every Purchase Voucher

Every row in your import file must include these fields at minimum:

Field	Description	Critical Notes
Voucher Date	Date of the purchase transaction	Must match your TallyPrime date format: typically dd-MMM-yyyy (e.g., 15-Mar-2026) or dd/MM/yyyy. A mismatched format fails silently or maps to an incorrect date.
Voucher Type	Must be set to "Purchase"	Tells TallyPrime which voucher class to create.
Party Name	Supplier or creditor ledger name	Must match the ledger name in TallyPrime's masters exactly, including spacing and punctuation.
Purchase Ledger	The purchase account to debit	Must reference an existing ledger under the Purchase Accounts group.
Amount	Transaction value	Use the currency format configured in your TallyPrime company (typically no currency symbol, with decimals as periods).
Voucher Number	Your invoice or reference number	Used to group line items into a single voucher and to prevent duplicates.

The number-one cause of failed imports is a name mismatch. If your import file lists a supplier as "Raj Enterprises Pvt Ltd" but TallyPrime's ledger reads "Raj Enterprises Private Limited," the row will fail. Before importing, export your ledger master list from TallyPrime and cross-check every party name and purchase ledger name against it.

GST-Specific Fields

If you are importing GST-applicable purchase vouchers, and most Indian businesses are, you need additional fields to ensure your data flows cleanly into GST returns and GSTN reconciliation:

Field	When Required	Format / Notes
Supplier GSTIN	All GST-registered supplier invoices	15-character alphanumeric (e.g., 27AABCU9603R1ZM). Must match the GSTIN recorded in the supplier's ledger master.
Place of Supply	All taxable transactions	State name or state code as configured in TallyPrime. Determines intra-state vs. inter-state tax treatment.
GST Rate	All taxable line items	Percentage value (e.g., 18 for 18%).
CGST Amount	Intra-state transactions	Central GST component. For an 18% rate, this is 9% of the taxable value.
SGST Amount	Intra-state transactions	State GST component. Must equal the CGST amount for standard splits.
IGST Amount	Inter-state transactions	Integrated GST. Used instead of CGST/SGST when buyer and supplier are in different states.
HSN / SAC Code	Required for turnover above threshold	Harmonized System of Nomenclature code for goods or Service Accounting Code for services.

Getting these fields wrong does not just cause import errors. It creates reconciliation problems that surface weeks later during GST filing. According to Deloitte India's GST@7 survey, 37 percent of Indian MSMEs still report challenges with GST invoice-matching and reconciliation, down from 64 percent in 2023. Structuring your GST fields correctly at the import stage prevents these matching failures before they ever reach the GSTN reconciliation process.

For intra-state purchases, both the CGST and SGST columns must be populated. For inter-state purchases, use the IGST column and leave CGST/SGST empty. Mixing these up or populating all three simultaneously will produce incorrect tax entries that break your GSTR-2B matching.

Before preparing your import file, review the mandatory fields for GST-compliant invoices under Rule 46 to confirm your source invoice data captures every required field.

Row Structure for Multi-Line Vouchers

When a single purchase invoice contains multiple line items, each item occupies its own row in the import file. Voucher-level fields must be repeated on every row belonging to the same invoice:

• Row 1: Voucher date, party name, voucher number, purchase ledger for Item A, amount, HSN code, GST details
• Row 2: Same voucher date, same party name, same voucher number, purchase ledger for Item B, amount, HSN code, GST details
• Row 3: Same header fields repeated, line-item details for Item C

TallyPrime groups these rows into a single purchase voucher based on the voucher number, or when voucher numbers are absent, a combination of voucher date and party name. If you omit the voucher number and two invoices from the same supplier share the same date, TallyPrime will merge them into one voucher. Always include a unique voucher number per invoice to avoid this.

With this row structure in place, TallyPrime reconstructs each multi-line purchase voucher exactly as if you had entered it through the manual voucher screen, with all line items, tax breakdowns, and totals intact.

Mapping Templates and the Import Data Workflow

The actual import process in TallyPrime follows a predictable sequence, but the difference between a painful one-off exercise and a repeatable workflow comes down to one feature: mapping templates.

Start the import from Gateway of Tally. Navigate to Import Data, then select your source file (Excel, XML, or JSON). Set the voucher type to Purchase so TallyPrime knows which ledger structure and mandatory fields to enforce. The system then presents you with a column mapping screen where each column in your source file needs to be assigned to the corresponding TallyPrime field.

This mapping step is where most of the initial effort lives. You are telling TallyPrime that column A is your invoice number, column B is the supplier name, column C holds the invoice date, and so on through every required and optional field. For a first import, expect to spend time here getting each assignment right.

Save the mapping as a reusable template. Once you have mapped every column correctly, TallyPrime lets you save this configuration as a named template. On your next import using a file with the same column structure, you select the saved template instead of re-mapping from scratch. The time savings compound quickly. CA firms and bookkeeping practices handling monthly batch imports from multiple clients benefit most here. Each client typically sends data in a consistent format month after month. One template per client eliminates repetitive setup and reduces the chance of mapping errors creeping in during manual reassignment.

Use the preview before committing anything. TallyPrime displays a preview of how your source data will translate into purchase vouchers before writing to the ledger. Do not skip this step. The preview reveals field mismatches, missing mandatory values, and incorrect voucher grouping that would otherwise create errors you have to clean up after the fact. Scan for blank cells in critical fields like GSTIN, invoice number, and tax amounts. Verify that line items are grouped under the correct voucher rather than split into separate entries.

For large files containing hundreds of vouchers, TallyPrime's own documentation recommends importing in manageable batches rather than loading everything at once. If a malformed row causes a rejection, you are troubleshooting 50 vouchers instead of 500. After each batch finishes, check the Exceptions Report and Event Log before moving on. TallyPrime logs every failed or warned voucher there, and catching silent issues (a tax amount that defaulted to zero, a supplier ledger auto-created with incorrect grouping) is far cheaper at this stage than during GST reconciliation.

---

When Invoices Arrive as PDFs or Scans

The sections above cover how to import structured data into TallyPrime. The actual bottleneck for most teams is not the import step itself but everything that happens before it: extracting the right fields from unstructured documents (PDFs, scans, photos), structuring them into Tally-compatible columns, and formatting values so the import does not choke on date mismatches or GST calculation errors.

The extraction-to-import pipeline looks like this: pull data from the source PDF or image, map it into the exact fields TallyPrime expects (the same ones covered in the purchase voucher field reference above), output the result as Excel or JSON, then feed it through the mapping template workflow covered in the previous section. When you are processing ten invoices, doing this manually is tedious but survivable. When you are processing hundreds during a GST filing period or migrating a year of historical purchase data, it becomes the single largest time sink in the entire workflow.

A document extraction tool configured for TallyPrime output eliminates the manual reformatting layer entirely. Invoice Data Extraction lets you extract invoice data from PDFs into structured spreadsheets by prompting the AI with the exact column names and formatting rules your import file needs. You can instruct it to produce columns named Voucher Date, Party Name, Purchase Ledger, GSTIN, HSN Code, CGST Amount, SGST Amount, and IGST Amount, matching your TallyPrime mapping template one-to-one. The same prompt can enforce date formatting (dd-MMM-yyyy) and two decimal places on all currency fields, so the output file requires zero manual adjustment before import.

For teams dealing with large supplier bases, the batch processing capability handles large volumes of mixed-format files (PDFs, scanned images, photographs) in a single job. You write the extraction prompt once, specifying your Tally field names and formatting rules, then save it to the prompt library for reuse every filing cycle. This turns a recurring multi-hour data entry task into an upload-and-download workflow that produces the same consistent output each time.

One workflow worth noting for teams with developer resources or automated pipelines: extraction tools that output JSON can feed directly into TallyPrime 7.0's JSON import path, bypassing the spreadsheet intermediary altogether. If your extraction prompt already structures data with the correct field hierarchy and GST breakdowns, the JSON output maps cleanly to Tally's expected schema without an additional conversion step.

A final consideration for reverse charge mechanism transactions. When the buyer is liable to pay GST under RCM, the import file needs additional fields and a different voucher structure compared to standard purchase vouchers. The Party Name, tax ledger mappings, and self-invoice details all change. If your invoice batch includes RCM supplies, review the self-invoice requirements for reverse charge supplies under GST before building your extraction template, so the output file captures every field the RCM voucher entry requires.

---

Common TallyPrime Import Errors and How to Fix Them

The errors below account for the vast majority of TallyPrime import failures, and most trace back to a small number of data-quality issues in the source file.

Voucher Totals Do Not Match

This is the single most common import rejection. TallyPrime validates that the sum of all line-item amounts plus all tax components (CGST, SGST, IGST, cess) exactly equals the voucher total. If there is any discrepancy, even one paisa, the voucher is rejected.

The usual culprits:

• Rounding differences in tax calculations. If you calculate tax at the line-item level and round each component independently, the sum of rounded values may differ from the rounded total. Pick one rounding approach and apply it consistently.
• Missing line items. A row was dropped or filtered out during file preparation, so the line-item sum falls short of the stated total.
• CGST/SGST split errors. For intra-state transactions, the total GST must split evenly into CGST and SGST. Odd-paisa splits cause mismatches when TallyPrime recalculates.

Fix: Use at least two decimal places for every amount field. Recalculate the voucher total as the sum of line items plus tax components in your spreadsheet before importing, rather than relying on a separately stated invoice total.

Ledger Not Found

TallyPrime requires an exact name match between the party ledger or purchase ledger in your import file and the corresponding entry in the Chart of Accounts. There is zero tolerance for variation. "M/s Sharma Traders" will not match "Sharma Traders," and an extra trailing space will cause a failure.

Fix: Before preparing your import file, export your current ledger list from TallyPrime (Gateway > Display More Reports > List of Accounts). Use this export as a lookup reference. Run a comparison against the supplier names in your import data and correct every mismatch. For recurring imports, maintain a supplier name mapping table that translates names from your source system to TallyPrime's master data.

GST Registration and Location Errors

When the GSTIN in your import file does not match the GST registration details stored in the party ledger master within TallyPrime, the voucher may import but will create reconciliation problems downstream. These mismatches surface during GSTR-2A/2B reconciliation, often weeks later, when they are harder and more time-consuming to fix.

A missing or incorrect place of supply creates a different class of problem: it can cause TallyPrime to apply IGST where CGST/SGST should apply, or vice versa, producing incorrect GST returns.

Fix: Verify that every supplier's GSTIN in the import file matches the GSTIN stored in their TallyPrime ledger master. For inter-state transactions, ensure the place of supply field is populated on every row. Cross-check a sample of entries against the GST portal's taxpayer search to catch stale or incorrect GSTINs.

Row Grouping and Bill-Detail Splitting

You import a file expecting 50 purchase vouchers, but TallyPrime creates 200. Each line item became its own voucher instead of being grouped with the other line items from the same invoice. This happens when the grouping key is inconsistent across rows that should belong to a single voucher.

TallyPrime typically groups rows into a single voucher based on a combination of voucher number, date, and party name. If any of these fields differ across rows, even slightly, TallyPrime treats them as separate vouchers. A common trigger: the voucher date is formatted as "15-Mar-2026" on one row and "15/03/2026" on another row of the same invoice.

Fix: Ensure every row belonging to the same voucher has identical values in all grouping fields. Copy-paste the grouping values rather than retyping them. After preparing your file, sort by voucher number and visually inspect the grouping fields for inconsistencies.

Date Format Mismatches

Date errors are particularly dangerous because they can fail silently. A date that TallyPrime cannot parse may be quietly mapped to an incorrect date rather than triggering a visible error. You end up with vouchers posted to the wrong period, which may not be caught until month-end reconciliation or GST filing.

Fix: Check TallyPrime's expected date format under Company Features > Numeric Format. Then ensure every date value in your import file uses that exact format. When in doubt, standardize to dd-MMM-yyyy (e.g., 15-Mar-2026), which avoids the day/month ambiguity that plagues numeric-only formats and is broadly compatible across TallyPrime configurations.

After Every Import: Check the Exceptions Report

Do not assume a completed import means a successful one. After every import run, open TallyPrime's Exceptions Report and review the Event Log. The Exceptions Report lists each voucher that failed validation and the specific reason for rejection. The Event Log captures warnings that did not block the import but may indicate data-quality issues, such as duplicate voucher numbers or ledger auto-creation events. These two reports are your first diagnostic step whenever import results do not match expectations.