Skip to content

Tally

Applies to: e-Invoice · e-Way Bill · Which modules do I have?

Purpose

Connect Tally to Complifly, either through a scheduled export and upload or through a connector calling the ingest API, and set out the traps specific to Tally's data model.

Audience

Tally partners, implementation consultants and integration developers.

Prerequisites

  • The Integration Pattern — read first
  • Access to the Tally installation
  • Sandbox credentials
  • A raw export sample per voucher type

Verify: Whether Complifly supplies a Tally connector or this is a pattern a partner implements is not established here. Recorded as assumption F1 in the Assumptions Register.

Steps

1. Choose the approach

Approach Suits Trade-off
Connector to mapped ingest Ongoing, higher volume Development effort; needs Tally to be reachable or to call out
Scheduled export and upload Lower volume, minimal change A manual or scheduled step; rejections found later
Manual export and upload Very low volume, or a pilot Entirely manual; not sustainable at volume

Tally installations are frequently on-premises, single-machine and not continuously connected. Choose realistically: a connector requiring constant connectivity is a poor fit for a machine that is switched off at night.

2. Handle Tally's data model

Tally differs from larger systems in ways that shape the mapping:

Characteristic Consequence
Vouchers, not typed documents The voucher type determines the document type — a lookup rule, and its default matters
Registration on the company or ledger Establish which carries it in this installation before mapping
Ledger-driven tax Tax amounts derive from ledger allocations rather than explicit fields
Flexible field usage Customers use fields in idiosyncratic ways; the mapping must reflect this installation
Multiple companies in one installation Each may be a different registration

The fourth row is the important one. A Tally mapping built for one customer rarely transfers to another without change, because two installations rarely use the same fields the same way. Budget for per-customer mapping work.

3. Source the required fields

Complifly needs Typically from
Document number and date Voucher number and date
Document type Voucher type, through a lookup
Supplier registration Company or ledger registration details
Buyer registration and address Party ledger master
Place of supply Determined in Tally; a tax position
Values Voucher totals
Line details Inventory entries
Classification codes Stock item master

Once you know where each value lives, build the translation in the product rather than in ERP code: Build a Mapping Template walks through creating the template, loading these fields from a sample, and dragging them onto their NIC counterparts with the right direct, date or lookup rule.

4. Handle the Tally traps

Trap Symptom Fix
Voucher type variety Documents route wrongly Enumerate every voucher type in use and map each explicitly. A permissive default misclassifies
Date format Dates transposed Declare the export's exact format; test with an unambiguous date
Voucher numbering resets Duplicate rejections Confirm numbering is unique per registration per financial year. Tally numbering commonly restarts
Optional and cancelled vouchers Sending something not final Exclude them from the export
Tax derived from ledgers Tax amounts absent or wrong Map from the ledger allocations, with the customer's accountant confirming which
Multi-company installations Wrong registration One template per company where they differ
Character encoding Names mangled Confirm the export encoding is UTF-8

The numbering trap is the most common and the most expensive: once a number is registered it is permanently consumed, so a restarted series collides forever.

5. Return the outcome

Tally's ability to accept an inbound update varies by installation. Options, in order of preference:

Option Note
Connector writes back into Tally Best, where the connector supports it
A report the customer reconciles against Practical and common
Complifly as the compliance record of record Acceptable where Tally does not need the reference number

Decide this explicitly during implementation. Assuming write-back into Tally and discovering late that it is not feasible is a common late surprise.

6. Handle rejections visibly

Where uploads are scheduled, someone must review the results. Assign a person and a daily time. A scheduled upload nobody checks is a scheduled way to accumulate failures.

Documents the Desktop Agent sends that Complifly refuses are stored, with the reason, the agent that sent them and the voucher as it was sent. They are listed under intake refusals in Support Investigation and each refusal is in the audit log (AGENT_INGEST_DOCUMENT). The agent's receipt carries a rejectionId — quote it to support. Refusals from before 2026-10-02 were returned to the agent only and are not stored.

7. What the Desktop Agent does with each voucher

A voucher the agent sends ends in exactly one of five outcomes, and the customer cannot change which. What a customer or consultant configures is how Complifly reads Tally; what is owed to NIC follows from the law and is set by Complifly.

Outcome What it means What the customer sees
IRN only An e-invoice is due; no e-way bill The invoice is stored Pending, then gets an IRN
IRN and e-way bill Both are due As above; the e-way bill follows the IRN
e-Way Bill only No IRN, but an e-way bill is due (large B2C sale that ships; a challan; a bill of supply; a registration below the e-invoicing limit) Stored for the e-Way Bill Doc Workbench as EWB_PENDING; a user generates the bill there
Neither Nothing is due with NIC (a counter sale to a consumer; a small challan). Still reported in GSTR-1 Stored as NOT_APPLICABLE. This is not an error
Held Complifly cannot decide, so it sends nothing and does not assume The agent keeps the voucher; the receipt gives a heldReason (codes)

Availability. The agent endpoint is behind the AGENT_ENABLED organisation switch (off by default), and mTLS termination in front of it is not yet configured, so a customer's agent cannot reach it. This section describes what Complifly does with a voucher once it arrives; it does not mean a customer can be onboarded onto the agent today.

What works today, tested on synthetic vouchers (no real Tally export or live NIC call yet):

Sale type Status What the customer must have in Tally
Domestic B2B invoice Works Buyer GSTIN, tax ledgers, HSN on the item
B2C (B2CL, B2CS) Works: recorded NOT_APPLICABLE, or e-way bill only if it ships Dispatch details on the voucher if goods move; otherwise Complifly cannot tell
Export with or without payment Works if the buyer's country is a recognised name Country on the party ledger; for a zero-tax export the LUT written as LUT ARN <number> in the narration (low confidence)
SEZ supply Works only for party ledgers the customer's setup lists as SEZ The list of SEZ party ledgers, given to Complifly
Deemed export Works only for parties or a marker the customer's setup names A marker agreed with Complifly
Credit and debit notes Works; the original invoice is sent only if its Tally field is configured The field holding the original invoice number and date
Delivery challan, job work, bill of supply Works only after the customer's setup enables it and maps each voucher type to a reason (the customer lists its voucher type names per kind of movement; Material Out and Material In are the shipped defaults, mapped to job work and job work return) One voucher type per purpose
Stock transfer Held until the customer's setup says whether transfers are documented by a challan or a tax invoice (stockTransferMode). A compliance decision; nothing is assumed The answer, plus the other GSTIN for a tax-invoice transfer

Settings Complifly records per customer (all optional, all read-side; none changes what is owed): SEZ party ledgers, the deemed-export marker, where the LUT or bond is held and whether to read it from a field, the narration or both (lutSource), where a note names its original invoice, which voucher types are challans and for what purpose, the stock-transfer mode, how a Bill of Supply is flagged, and which voucher fields carry the vehicle, transporter and delivery document. Complifly support enters them; there is no customer screen for this yet.

The turnover band is a fact only the customer can state. Whether a B2B invoice needs an IRN depends on whether the registration is above the e-invoicing limit. Until Complifly records the band for a GSTIN it is UNKNOWN_TURNOVER: documents are not held; they are routed as if the registration is above the limit, carry the warning UNKNOWN_TURNOVER, an audit entry AGENT_UNKNOWN_TURNOVER is written, and one onboarding task is opened for the GSTIN (it closes when the band is declared). A registration below the limit that is not recorded as such will be sent for IRNs it should not raise, so declare the band at onboarding.

Compliance placeholders. The obligation rules added for exports with payment, SEZ without payment, deemed exports, debit notes, non-B2B credit notes, challans and bills of supply are marked as placeholders pending confirmation of the live notification and citation. Documents are routed by them, but they have not been confirmed by Complifly's compliance review.

Validation

Check Method Pass condition
Every voucher type mapped Export one of each Each routes correctly
Numbering is safe Review the series across years and companies No possibility of collision
Dates correct Export a voucher dated the fifth of March Stored as intended
Tax amounts correct Compare the mapped payload against the voucher Exact match
Cancelled and optional vouchers excluded Create one of each Not sent
Multi-company handled Export from each company Correct registration each time
Encoding correct Export a name with non-ASCII characters Renders correctly
Multi-line correct Export a voucher with several items Every line present
Each sale type routes as expected Send one voucher of each type the customer issues The outcome in section 7 for each; nothing Held that should not be
Outcome path agreed Confirm with the customer Documented and working
Rejections reviewed Force one A person sees it the same day

Troubleshooting

Symptom Cause Action
Documents route to the wrong pipeline Voucher type not mapped, and the default guessed Map every type explicitly
Duplicate rejections Voucher numbering restarted Fix the series. Registered numbers are permanently consumed
Tax amounts missing Derived from ledgers, not mapped Map the ledger allocations, confirmed by the accountant
Names show wrong characters Encoding mismatch Export as UTF-8
Dates transposed Format not declared correctly Correct and re-test with an unambiguous date
Cancelled vouchers registered Not excluded Exclude. A registered document cannot be un-registered
Wrong registration Multi-company installation with one template One template per company
Uploads stop and nobody notices Scheduled task failed silently Monitor the schedule and alert on failure
Mapping from another customer does not work Field usage differs per installation Build the mapping against this installation's export
An SEZ or deemed-export sale was filed as an ordinary B2B sale The customer's setup does not list the SEZ party or name a deemed-export marker, and Complifly cannot detect either by itself Give Complifly the party ledgers or the marker. Already-filed IRNs cannot be edited
Retail invoices show NOT_APPLICABLE They need no IRN Nothing to fix. See section 7
A challan is Held with MOVEMENT_PURPOSE_UNMAPPED The voucher type is used for several purposes Agree one purpose per voucher type and send the list to Complifly support