Tell the customer which of four outcomes each of their sales and movements falls into, then configure only what moves a voucher between them. Every voucher the Complifly Agent sends ends as IRN only, IRN and e-way bill, e-way bill only, neither (recorded as NOT_APPLICABLE, and not an error), or held (Complifly could not decide and sent nothing). What the customer or consultant configures is how Complifly reads Tally; what is owed to NIC is set by Complifly because it follows the law, and no setting changes it.
This guide covers seventeen cases. Behaviour is taken from the code and tested on synthetic vouchers only: no real Tally export and no live NIC call has been used yet, so every Tally field marked unconfirmed below is a configurable placeholder, not a verified field name.
The agent endpoint is behind the AGENT_ENABLED organisation switch (off by default), and mTLS termination in front of it is not yet configured in the repository, so a customer's agent cannot reach it yet.
A Complifly Super Admin to record the customer's profile settings and turnover band in Administration > Compliance Profiles. The customer's Org Administrator can open that screen and read every setting, but cannot change any: agree with your Complifly implementation consultant how a change is requested before the call. See Compliance Profiles.
A raw Tally export of one voucher of each type the customer issues. It is what confirms the unconfirmed fields.
Every case below answers the same eight questions in the same order: (1) what the customer sets up in Tally, (2) which fields Complifly reads, (3) which profile setting controls it, (4) how Complifly decides which scenario or movement purpose it is, (5) the outcome, (6) the route, (7) readiness today, (8) what it still depends on.
Route
Stored as
Meaning
IRN
Pending
An IRN is generated; for IRN and e-way bill the e-way bill follows it
EWB only
EWB_PENDING
Waits in the e-Way Bill Doc Workbench for a user to generate the bill
None
NOT_APPLICABLE
Recorded and reportable; nothing is sent to NIC
Held
not stored
Nothing sent; the agent keeps the voucher; the receipt names the cause
A party ledger with a GST registration type of Regular, a GSTIN and a state; a Sales voucher with CGST and SGST ledgers (IGST for another state); an HSN or SAC on each stock item
Fields expected
PARTYGSTIN, PLACEOFSUPPLY, voucher type Sales, tax ledger entries (by duty head), stock item name and HSN, quantity, rate, amount
Profile configuration
None per customer. Base profile voucherTypeMap, ledgerClasses, unitMap
Scenario determination
Not SEZ, not foreign, not deemed export, buyer GSTIN present: B2B
Outcome
IRN only; IRN and e-way bill if dispatch details exist and the value is INR 50,000 or more. Below the e-invoicing limit: e-way bill only, or neither
Route
IRN (Pending); the e-way bill follows the IRN
Readiness
Built and tested on synthetic vouchers; the case to pilot first
Still depends on
A real export to confirm field names; the turnover band declared; the e-way bill value limit confirmed by compliance; mTLS on the fleet
A consumer or unregistered party (no GSTIN) in another state; an invoice at or above the B2CL threshold (INR 50,000 today, a compliance placeholder)
Fields expected
Absence of PARTYGSTIN, PLACEOFSUPPLY, the voucher total
Profile configuration
None. Dispatch fields via transportFields once confirmed
Scenario determination
No GSTIN, inter-state, total at or above the B2CL threshold: B2CL
Outcome
e-way bill only when the value is INR 50,000 or more, whether or not the voucher carries dispatch details. When it does not, the document carries MOVEMENT_UNKNOWN_AT_THRESHOLD and the shipping details are completed in the e-Way Bill Doc Workbench. Below INR 50,000: neither. Never an IRN
Route
EWB only (EWB_PENDING), or None (NOT_APPLICABLE) below INR 50,000
Readiness
Built and tested. No longer rejected as an IRN document
Still depends on
Compliance: the B2CL threshold. It is registry data (INR 50,000 today, flagged as a placeholder because it was INR 1,00,000 before and 50,000 is also the e-way bill limit); the dispatch field names
A consumer or unregistered party; an intra-state sale, or an inter-state sale below the B2CL threshold
Fields expected
Absence of PARTYGSTIN, PLACEOFSUPPLY, the voucher total
Profile configuration
None
Scenario determination
No GSTIN and not B2CL: B2CS
Outcome
Neither below INR 50,000. At INR 50,000 or more: e-way bill only, whether or not the voucher carries dispatch details (flagged MOVEMENT_UNKNOWN_AT_THRESHOLD when it does not). Never an IRN
Route
None (NOT_APPLICABLE) below INR 50,000: tell a retail customer to expect many of these. EWB only (EWB_PENDING) at or above it: the shipping details are added in the e-Way Bill Doc Workbench, and a counter sale that does not ship is simply not generated
A foreign party with its country on the ledger; an Export Sales voucher with IGST charged
Fields expected
COUNTRYOFRESIDENCE, tax ledger entries
Profile configuration
countryHandling (India's spellings). The country name is converted to its ISO code by Complifly. exportCurrency.symbols (same screen, per company): the currency symbol Tally writes on a foreign-currency voucher ($) to the ISO code NIC needs (USD); the shipped table covers $, €, £, ¥, and $ means US dollars, so a company billing in another dollar currency changes that one entry. Complifly sends the rupee amounts Tally itself posts (the figure after the = sign) and the foreign invoice total separately. exportBuyer.pin (Admin > Compliance Profiles > Export & special supply, per company, default 999999): on an export the buyer's PIN sent to NIC is this value, replacing the PIN Tally sent, including an empty one, so an overseas party needs no PIN in Tally. Empty the setting to send the PIN as Tally holds it. Place of supply and buyer state are 96 and the buyer GSTIN is URP automatically, because NIC fixes those values for an export; leave the GSTIN empty on the overseas party in Tally. exportPort (the Indian port the goods ship from, per company) is needed for the e-way bill, see the export port
Scenario determination
Foreign buyer, tax charged: EXPWP, place of supply 96
Outcome
IRN only (IRN and e-way bill if it ships). If it ships and no export port is set, the voucher is held (EXPORT_PORT_NOT_CONFIGURED)
Route
IRN
Readiness
Built and tested; the obligation rule is a compliance placeholder
Still depends on
Compliance confirming the rule; a country name Complifly recognises (otherwise the document is rejected with COUNTRY_NOT_ISO)
An export that needs an e-way bill is held until the company has an export port. NIC wants the ship-to of an export e-way bill to be a domestic port, ICD or CFS (state and PIN in India), never the overseas consignee. TallyPrime holds no such address, so the customer's port is set once on Admin > Compliance Profiles > Export & special supply > Export Configuration by a Complifly Super Admin. You cannot set it from the agent or from Tally.
Setting
Rule
Port name, address line 1, city, state code, PIN
Required together. State 01 to 38 (never 96). PIN six digits. Address line 2 is optional. A partial port is refused on save.
Ship-to GSTIN
Always URP; the port name is the ship-to name
Shipping bill number and date
Read from the voucher's SHIPPINGBILLNO and SHIPPINGBILLDATE when present; left out when absent
Port code (PORTCODE, such as INDEL4)
Not used. A code is not an address, and nothing is looked up from it
Overseas consignee on the voucher
Never copied into the ship-to, even if the profile maps a ship-to from the consignee fields
Export outcome
No port set
Port set
IRN only
Filed, with the warning EXPORT_PORT_NOT_CONFIGURED; an onboarding task CONFIGURE_EXPORT_PORT is opened
Filed with the port as ship-to
IRN and e-way bill, or e-way bill only
Held, not stored; the same task is opened
Filed with the port as ship-to
Held vouchers are not kept by Complifly: after the port is saved, send them again from Tally. Machine A needs the current base.v6.json, which adds SHIPPINGBILLNO and SHIPPINGBILLDATE to what the agent may send. Until it is replaced the shipping bill is simply absent. The port itself needs nothing from the agent.
Not yet proved against NIC: the mapping is tested, but no NIC sandbox run with a real port address has been done. Test with a real Indian port address before relying on it.
A party ledger registered as an SEZ unit or developer; IGST charged
Fields expected
The party's GST registration type, which TallyPrime exports as GSTREGISTRATIONTYPE ("Regular - SEZ"), or the party ledger name
Profile configuration
buyerRegistration.sourceField (set it to GSTREGISTRATIONTYPE; the agent's base.v6.json must allow that field) and buyerRegistration.partyOverrides (works without it: list the SEZ party ledgers)
Scenario determination
Registration type SEZ_UNIT or SEZ_DEVELOPER, tax charged: SEZWP
Shipping bill
Not sent. A supply to an SEZ unit is not an export, so a shipping bill number on the voucher is ignored; only a real export carries one. (Sending it made NIC's export block appear, which demands a currency and a country)
Outcome
IRN only (IRN and e-way bill if it ships)
Route
IRN
Readiness
Built and tested through the party list. Without either setting an SEZ buyer is silently treated as ordinary B2B, so the setting is mandatory for an SEZ customer
Still depends on
The Tally field holding the registration type (real export)
A marker the customer's accountants already use for deemed exports, on the party or the sales ledger
Fields expected
The marker (field name unconfirmed)
Profile configuration
deemedExport.sourceField + trueValues, partyOverrides (list the deemed-export parties; works today), narrationPattern (weakest)
Scenario determination
Marker true, domestic: DEXP. Tested before the buyer-GSTIN check, because a deemed-export buyer is a registered person. No marker configured: buyer.deemedExport is unknown (null), never false
Outcome
IRN only
Route
IRN
Readiness
Built and tested through the party list; the obligation rule is a compliance placeholder
Still depends on
Compliance: the final DEXP interpretation; the marker field name (real export)
A Credit Note or Sales Return voucher that names the invoice it corrects
Fields expected
VOUCHERTYPENAME, the buyer fields as for the original sale, the original invoice number and date (fields unconfirmed)
Profile configuration
voucherTypeMap; originalInvoiceRef.numberField and dateField
Scenario determination
The buyer's scenario, with document type CRN
Outcome
IRN only where the original needed one; neither for a B2C note or a registration below the limit. Never an e-way bill
Route
IRN, or None
Readiness
Built and tested. The original invoice is sent as RefDtls.PrecDocInvNo / PrecDocDt once its field is configured; otherwise the note is accepted with an adapter note
Still depends on
The original-invoice field (real export); compliance: whether the preceding document is mandatory
Switch these on with movement.enabled = true in the customer's profile. A movement voucher has no supply scenario; it has a movement purpose, and the purpose decides the e-way bill sub-supply type.
A Delivery Note voucher type used for one purpose; if it is used for several, create one voucher type per purpose first
Fields expected
Voucher type, party and GSTIN, items, dispatch details, and the narration when the purpose is Material transfer (see below)
Profile configuration
movement.voucherTypeGroups.deliveryChallan (the voucher type names; default Delivery Note) and movement.groupPurposes.deliveryChallan (default null)
Reason text for Material transfer
NIC files Material transfer as Others and requires a short description. Complifly sends the voucher's narration when one is typed, otherwise "Material transfer". NIC allows at most 20 characters, so a longer narration is cut to 20 (at a word boundary when it can be); keep the narration short, for example "Samples for approval". Job work, job work return and exhibition need no description
Movement determination
The purpose the profile gives the voucher type. Null: held (MOVEMENT_PURPOSE_UNMAPPED); Complifly will not guess, because Tally uses the same voucher type for several
Outcome
e-way bill only, or neither under the value limit. Never an IRN
Route
EWB only (EWB_PENDING, document type CHL), or None
Readiness
Built and tested once the purpose is configured
Still depends on
The Delivery Note voucher type name and its fields (real export); the e-way bill value limit
Voucher type, job worker ledger and GSTIN, items, dispatch details
Profile configuration
Default: Material Out maps to purpose JOB_WORK, outward, NIC sub-supply type 4
Movement determination
The profile's purpose for the voucher type: JOB_WORK
Outcome
e-way bill only, or neither under the value limit. Not a supply, so no IRN
Route
EWB only (CHL, Supply_Type O, Sub_Type 4)
Readiness
Built and tested
Still depends on
Compliance: job work's statutory treatment and its e-way bill value rule (the general INR 50,000 is carried over as a placeholder); the voucher type name (real export)
A Material In voucher for processed goods coming back
Fields expected
As job work
Profile configuration
Default: Material In maps to JOB_WORK_RETURN, inward, sub-supply type 6
Movement determination
JOB_WORK_RETURN. Inward: the company is the consignee and the taxpayer; the job worker is the consignor. The job worker's GSTIN need not be bound to the agent
Outcome
e-way bill only, or neither under the value limit
Route
EWB only (Supply_Type I, Sub_Type 6), filed under the company's GSTIN
Readiness
Built and tested, including the storage under the consignee
The Material Out voucher type. If the customer also uses it for something other than job work, split it first
Fields expected
As job work
Profile configuration
movement.voucherTypeGroups.materialOut (the names) and movement.groupPurposes.materialOut (default JOB_WORK): change the purpose if it is not job work. Voucher types that are always job work can go in jobWorkOut instead
Movement determination
The configured purpose; the default is JOB_WORK
Outcome
As job work
Route
EWB only, or None
Readiness
Built and tested. The default mapping is unconfirmed against a real export
Still depends on
The voucher type's exact name and fields (real export)
movement.voucherTypeGroups.materialIn (the names) and movement.groupPurposes.materialIn (default JOB_WORK_RETURN). The group is inward by definition; an outward purpose is held (MOVEMENT_DIRECTION_MISMATCH). Always-job-work-return voucher types can go in jobWorkReturn
Movement determination
The configured purpose; the default is JOB_WORK_RETURN
Outcome
As job work return
Route
EWB only (inward)
Readiness
Built and tested
Still depends on
The voucher type's exact name and fields (real export)
A voucher type used only for transfers between the company's own locations, listed in movement.voucherTypeGroups.stockJournal (Complifly ships Stock Journal there)
Fields expected
Voucher type, the other location's GSTIN, items, dispatch details
Profile configuration
stockTransferMode: CHALLAN or INVOICE. Unset by default
Movement determination
CHALLAN: a challan with purpose STOCK_TRANSFER (sub-supply type 5, For Own Use: a placeholder code). INVOICE: an ordinary taxed invoice to the other GSTIN (B2B, IRN). Unset: held (MOVEMENT_PURPOSE_UNMAPPED with a STOCK_TRANSFER_MODE_UNSET note)
Outcome
CHALLAN: e-way bill only, or neither. INVOICE: IRN only, or IRN and e-way bill
A Stock Journal as Tally exports it
It names no party, carries no HSN and no transport details. With CHALLAN, Complifly treats the company itself as the receiver (a same-GSTIN transfer) and, because nothing says the goods travel, records the transfer as not applicable: it is accepted and stored, with no e-way bill. A transfer that needs an e-way bill must be entered on a voucher that carries the item GST details and the transport details (a Delivery Note or Material Out, for example). INVOICE cannot work for a Stock Journal, because an invoice needs a buyer
Route
EWB only, or IRN
Readiness
Built and tested in all three states; no legal treatment is assumed
Still depends on
Compliance: which form applies, and the sub-supply code for a challan transfer