Get ledgers (accounts) from TallyPrime. Omit query to get every ledger. Pass query to instead get a fuzzy-ranked shortlist of the closest-matching ledger names — useful when you have a rough or partial name (e.g. from a client document) and need Tally's exact spelling before creating a voucher or a new ledger, without pulling and scanning the entire ledger list yourself. Matches on exact/prefix/substring, then falls back to a loose in-order character match for abbreviations and typos (e.g. 'vro' finds 'VRO Technology'). Returns at most the top 20 matches, ranked best first; an empty result means create the ledger — nothing close enough exists yet. Each ledger includes VATTINNUMBER, STATE, and COUNTRY (the values set via create_ledger's trn/state/country fields, blank if never set) — check these before creating a Sales/Purchase invoice (or Credit/Debit Note, Delivery/Receipt Note) for that party: Tally itself defaults a new invoice's Buyer/Place-of-Supply details from the party ledger's own master data, so use these same values for buyerTrn/buyerState/buyerCountry rather than leaving them blank or guessing. Only ask the user to confirm instead of defaulting when the party has multiple registered delivery locations/addresses and it's genuinely unclear which one applies to this specific transaction (confirmed live: a real customer ledger can carry dozens of named addresses, and one invoice's Buyer address and Consignee/Ship-to address can legitimately differ from both the ledger's default and each other).

Get all stock items from TallyPrime

Get vouchers (Day Book) from TallyPrime filtered by date range. Returns a flat array of rows (guid, date, voucher_type, voucher_number, reference, party_ledger, amount, narration) — headers only, no stock item or ledger line detail (use get_ledger_vouchers or query_sql for that). Rebuilt on the same Voucher collection query sync_vouchers_to_sql already uses: an earlier version called Tally's canned 'Day Book' report directly, which was confirmed live to silently ignore the date range entirely (returning the same fixed set regardless of what was requested, even for a year before the company's books start) — this version correctly scopes to the requested range.

Get the currently open company info from TallyPrime

Get the Profit & Loss statement from TallyPrime for a date range

Get the Balance Sheet from TallyPrime as of a given date

Get the Trial Balance from TallyPrime for a date range

Get all account groups (e.g. Sundry Debtors, Fixed Assets) from TallyPrime

Get all voucher types configured in TallyPrime (e.g. Payment, Sales, Journal)

Get all cost centres from TallyPrime

Get the Stock Summary report from TallyPrime as of a given date

Get outstanding Bills Receivable from TallyPrime as of a given date

Get outstanding Bills Payable from TallyPrime as of a given date

Get the Cash Flow statement from TallyPrime for a date range — Tally's own canned report, reachable directly via a plain Export Data request (confirmed live, unlike the VAT/GST return reports). Returns Tally's native monthly-period breakdown shape (DSPPERIOD/DSPACCINFO arrays) as-is.

Get the Funds Flow statement from TallyPrime for a date range — Tally's own canned report, reachable directly via a plain Export Data request. Returns Tally's native monthly-period breakdown shape as-is.

Get the Ratio Analysis report from TallyPrime for a date range (Working Capital, Current Ratio, Quick Ratio, Inventory Turnover, Debtors/Creditors Turnover, and similar standard ratios) — Tally's own canned report, reachable directly via a plain Export Data request. Returns Tally's native RATIONAME/value array shape as-is.

Get the Sales Register from TallyPrime for a date range — a month-by-month summary of Sales voucher activity, Tally's own canned report reachable directly via a plain Export Data request. For individual Sales voucher line detail (not just monthly totals), use get_vouchers or get_ledger_vouchers instead.

Get the Purchase Register from TallyPrime for a date range — a month-by-month summary of Purchase voucher activity, same design as get_sales_register.

Get the Journal Register from TallyPrime for a date range — a month-by-month summary of Journal voucher activity, same design as get_sales_register.

Get the Payment Register from TallyPrime for a date range — a month-by-month summary of Payment voucher activity, same design as get_sales_register. For Receipt vouchers specifically, use get_receipts_and_payments instead — Tally has no separate standalone 'Receipt Register' report reachable this way (confirmed live: 'Could not find Report').

Get the Receipts and Payments report from TallyPrime for a date range — a cash/bank-ledger-wise view combining Receipt and Payment activity, Tally's own canned report. This is the closest reachable equivalent to a standalone Cash Book/Bank Book — Tally's actual 'Cash Book'/'Bank Book' menu reports are not reachable via a plain Export Data request (confirmed live: 'Could not find Report'), even though they're registered report names — for a single cash or bank ledger's own transaction history instead, use get_ledger_vouchers with that ledger's name.

Get the Reorder Status report from TallyPrime for a date range — stock items with a reorder level configured, and where their current quantity stands against it (closingStock, onPurchaseOrder, onSaleOrder, reorderLevel, shortfall, minimumQty, requiredQty per row). Tally's own report returns every stock item regardless of reorder setup (confirmed live: a 10,770-item company with no reorder levels configured returned a ~1.4MB all-null dump) — this tool filters that down to only rows that actually have a reorder level set, since that's the only subset the report can say anything useful about. An empty rows array with a note means no items have a reorder level configured at all, not an error — use get_stock_summary for a plain quantity view of every item regardless of reorder setup.

Get a UAE VAT liability summary for a date range. Each row is a VAT ledger with its closing balance for the period, classified as input/output/rcm/other — 'rcm' (reverse charge) is kept separate from plain input/output because reverse-charge liability is the thing that's easily missed manually, even though it nets to a wash for most businesses — tagged with how it was found — 'structural' (Tally's own Type-of-duty/tax field is set to VAT on that ledger) or 'name_pattern' (matched Input/Output/Payable/Receivable VAT naming). Both signals are used together, not one alone — confirmed live on real company data that Tally's structural tag is precise but has near-zero recall: every properly-tagged ledger had a zero balance, while the ledgers actually carrying real money were created without that tag set at all. Not filtered by any particular parent group — real companies were confirmed to scatter these ledgers across many different groups, not one standard group. netTotal sums all rows using Tally's own debit/credit sign convention. Not Tally's canned VAT return report (confirmed live it isn't reachable via a plain Export Data request) — reconstructed from ledger balances the same way get_profit_and_loss is. If no matching ledgers exist, returns an explicit note instead of a bare zero — a company with no VAT ledgers (not registered, or unrecognizable naming) is a different fact from a real zero liability period.

Get an India GST liability summary for a date range. Same design as get_vat_liability_summary — each row is a GST ledger (CGST/SGST/IGST, input/output/payable/receivable/RCM) with its closing balance for the period, classified as input/output/rcm/other ('rcm' kept separate from input/output — reverse-charge liability is the thing that's easily missed manually), tagged 'structural' (Tally's Type-of-duty/tax field = GST) or 'name_pattern' (matched Input/Output CGST/SGST/IGST or GST Payable/Receivable/RCM naming) — both signals used together for the same reason: confirmed live that Tally's structural tag alone misses every ledger with real activity in a real company file. Deliberately excludes generic expense ledgers that merely mention GST in their name (a freight ledger, a GST write-off/ineligible-ITC ledger) — those aren't tax liability lines and including them would misstate the position. netTotal sums all rows using Tally's own debit/credit sign convention. Not a canned GSTR export — reconstructed from ledger balances. If no matching ledgers exist, returns an explicit note instead of a bare zero.

Get all voucher entries posted to a specific ledger within a date range

Create a new ledger (account) in TallyPrime, or rename/update an existing one by passing oldName

Delete one or more masters (ledger, group, stock item, voucher type, unit, godown, cost centre, etc.) from TallyPrime by name. If a master was used in a voucher you're also deleting, delete the voucher first and confirm it succeeded before calling this — doing both in the same parallel batch can race (the master delete reaching Tally before the voucher delete has committed), confirmed live. If a ledger/stock item was used in both a Sales AND a Purchase item-invoice, it may return 'Cannot be deleted!' permanently even with no transactions left — this is fixed by running Company Data → Rewrite in Tally itself (confirmed live), not by retrying or sequencing.

Switch TallyPrime's active company context. Changes which company subsequent tool calls and reports operate on — validate the name with get_ledgers/get_company_info or the company list first

Switch TallyPrime's active reporting period. Changes the global from/to date context used by Tally for subsequent report queries until changed again

Create a new voucher (e.g. Payment, Receipt, Sales, Purchase, Journal) in TallyPrime. Either pass debitLedger/creditLedger/amount for a simple 2-leg voucher, or pass 'entries' for a voucher with 3+ lines (e.g. one payment split across several expense ledgers). Normally omit voucherNumber and let Tally auto-number — but if Tally's numbering series doesn't pick up correctly (confirmed live: a company on a 'PNPC/2026/...' series silently restarted from '1' instead of continuing it), pass voucherNumber explicitly to force the value you want; check get_vouchers for the correct next number first.

Create a Stock Journal voucher in TallyPrime, moving inventory from one or more source stock items to one or more destination stock items (transfer, manufacturing-style conversion with multiple raw materials consumed and/or multiple finished/by-products produced, etc). Inventory-only — no ledger entries. Every source/destination line's godown is auto-filled only when this company has exactly one godown; if it has more than one (e.g. Dubai/Sharjah/Ajman), godown is required on each line and the call fails naming the available godowns rather than guessing (previously an omitted godown was silently dropped — blank EXCEPTIONS:1, no error text — this is now caught explicitly instead of guessing wrong).

Update an existing Stock Journal voucher in TallyPrime, replacing its source/destination lines and narration. Same fields as create_stock_journal, plus voucherNumber. Matched by date + voucher number — use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique. Refuses if another voucher type shares the same number on that date (confirmed live: Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one) — resolve the collision in Tally first if that happens.

Create a Material In voucher in TallyPrime — records stock received back from a job worker (or any party holding your material for processing), tracked against that party's ledger without a real accounting posting (this is Tally's job-work memorandum tracking, not a purchase). Uses Tally's native 'Multi Consumption Voucher View' shape. EXTRAPOLATED from a genuine Tally-exported XML template for this exact voucher type, not verified against a real manually-created example in this project — verify carefully after use, especially on a company with godown/batch tracking enabled (pass godown on every item). If creation fails with LINEERROR 'Voucher date is missing' even though the date field is set correctly, the date is outside Tally's active period (Alt+F2) — call set_period to cover it and retry (confirmed live).

Update an existing Material In voucher in TallyPrime, replacing its item lines and narration. Same fields as create_material_in, plus voucherNumber. Matched by date + voucher number — use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique. Refuses if another voucher type shares the same number on that date (confirmed live: Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one) — resolve the collision in Tally first if that happens.

Create a Material Out voucher in TallyPrime — records stock sent out to a job worker for processing, tracked against that party's ledger without a real accounting posting (job-work memorandum tracking, not a sale). Mirror of create_material_in. Same EXTRAPOLATED caveat and godown requirement apply. If creation fails with LINEERROR 'Voucher date is missing' even though the date field is set correctly, the date is outside Tally's active period (Alt+F2) — call set_period to cover it and retry (confirmed live).

Update an existing Material Out voucher in TallyPrime, replacing its item lines and narration. Same fields as create_material_out, plus voucherNumber. Same matching/collision caveats as update_material_in.

Create a Rejections In voucher in TallyPrime — records goods rejected and returned to you (e.g. by a customer or a job worker returning defective components). Inventory movement only, same shape as a Sales/Purchase item line but with no party ledger. EXTRAPOLATED: no confirmed real-world XML example was available for this exact voucher type — built by analogy to Tally's other inventory-only voucher shapes (Physical Stock). Verify carefully after use — godown is required on every item unless the company has exactly one godown, in which case it auto-fills. If creation fails with LINEERROR 'Voucher date is missing' even though the date field is set correctly, the date is outside Tally's active period (Alt+F2) — call set_period to cover it and retry (confirmed live).

Update an existing Rejections In voucher in TallyPrime, replacing its item lines and narration. Same fields as create_rejections_in, plus voucherNumber. Same matching/collision caveats as update_material_in.

Create a Rejections Out voucher in TallyPrime — records goods you're rejecting and returning outward (e.g. back to a supplier, or components you're sending back to a job worker as defective). Mirror of create_rejections_in. Same EXTRAPOLATED caveat and godown requirement apply. If creation fails with LINEERROR 'Voucher date is missing' even though the date field is set correctly, the date is outside Tally's active period (Alt+F2) — call set_period to cover it and retry (confirmed live).

Update an existing Rejections Out voucher in TallyPrime, replacing its item lines and narration. Same fields as create_rejections_out, plus voucherNumber. Same matching/collision caveats as update_material_in.

Create a Physical Stock voucher in TallyPrime — records a physical count and updates the stock item's book quantity to match it (that's the point of the voucher). Confirmed live against a real Tally-exported XML template (uses DIFFACTUALQTY=Yes at voucher level, not a per-line flag) after an earlier version of this tool was found to corrupt the closing balance to a nonsensical negative number — fixed and re-verified: counting 95 of an item that had 100 correctly closed the item at 95. It does not post any monetary/ledger write-off for the resulting shortage or excess value — do that separately with create_voucher if needed.

Update an existing Physical Stock voucher in TallyPrime, replacing its counted item lines and narration. Same fields as create_physical_stock, plus voucherNumber. Matched by date + voucher number — use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique. Refuses if another voucher type shares the same number on that date (confirmed live: Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one) — resolve the collision in Tally first if that happens.

Create an item-invoice Sales voucher in TallyPrime — a real invoice with stock item lines (quantity, rate), each posted to its own Sales ledger, plus one optional VAT/tax line on the total. Distinct from create_voucher, which only supports plain ledger-to-ledger entries with no stock items. WARNING (confirmed live): if the same party ledger or stock item is used in BOTH a Sales and a Purchase item-invoice, it can become undeletable via the API afterward (returns 'Cannot be deleted!' even with zero balance) — using it in only one of the two is fine and stays deletable. If it does happen, running Company Data → Rewrite in Tally itself clears it (confirmed live) — this is not a permanent lock.

Update an existing item-invoice Sales voucher in TallyPrime, replacing its item lines, party, and narration. Same fields as create_sales_invoice, plus voucherNumber. Matched by date + voucher number — use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique. Refuses if another voucher type shares the same number on that date (confirmed live: Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one) — resolve the collision in Tally first if that happens.

Create an item-invoice Purchase voucher in TallyPrime — mirror of create_sales_invoice for the buying side. A real invoice with stock item lines (quantity, rate), each posted to its own Purchase ledger, plus one optional VAT/tax line on the total. WARNING (confirmed live, same as create_sales_invoice): if the same party ledger or stock item is used in BOTH a Sales and a Purchase item-invoice, it can become undeletable via the API afterward — using it in only one of the two is fine and stays deletable. If it does happen, running Company Data → Rewrite in Tally itself clears it (confirmed live) — this is not a permanent lock.

Update an existing item-invoice Purchase voucher in TallyPrime, replacing its item lines, party, and narration. Same fields as create_purchase_invoice, plus voucherNumber. Matched by date + voucher number — use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique. Refuses if another voucher type shares the same number on that date (confirmed live: Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one) — resolve the collision in Tally first if that happens.

Create an item-invoice Credit Note in TallyPrime — a Sales return, reversing stock and revenue for returned items. Same shape as create_sales_invoice but with the debit/credit convention flipped, matching Purchase's sign pattern (a Credit Note is structurally a reverse Sales entry). Confirmed live on a real company: returning 5 units correctly increased the item's book quantity by exactly 5. Same godown and dual-role deletion caveats as create_sales_invoice apply.

Update an existing item-invoice Credit Note in TallyPrime, replacing its item lines, party, and narration. Same fields as create_credit_note, plus voucherNumber. Matched by date + voucher number — use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique. Refuses if another voucher type shares the same number on that date (confirmed live: Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one) — resolve the collision in Tally first if that happens.

Create an item-invoice Debit Note in TallyPrime — a Purchase return, reversing stock and expense for returned items. Same shape as create_purchase_invoice but with the debit/credit convention flipped, matching Sales's sign pattern (a Debit Note is structurally a reverse Purchase entry). Confirmed live on a real company: returning 3 units correctly decreased the item's book quantity by exactly 3. Same godown and dual-role deletion caveats as create_purchase_invoice apply.

Update an existing item-invoice Debit Note in TallyPrime, replacing its item lines, party, and narration. Same fields as create_debit_note, plus voucherNumber. Matched by date + voucher number — use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique. Refuses if another voucher type shares the same number on that date (confirmed live: Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one) — resolve the collision in Tally first if that happens.

Create a Delivery Note in TallyPrime — an item-line inventory voucher recording goods dispatched to a customer before or without a full Sales invoice (e.g. against a Sales Order). Same item-line shape as create_sales_invoice (stock item, quantity, rate, Sales ledger per line) but ISINVOICE is set to No and there's no VAT/tax line — a Delivery Note doesn't invoice the customer, it just moves stock out and records the reference. Distinct from create_rejections_out, which has no party/ledger amount at all. IMPORTANT (confirmed live): the Delivery Note voucher type must be active in the company first — check in Tally's UI (voucher types can be turned off per company) — otherwise the API still reports CREATED:1 even though the voucher won't show up in any report or be findable by get_vouchers/delete_voucher until the type is turned on. Once active, get_vouchers and delete_voucher find it correctly. get_ledger_vouchers will still never show it, by design, not a gap — that tool deliberately excludes inventory-classified vouchers (see its own description). ALSO confirmed live: Delivery Note can silently stop auto-numbering via the gateway, same failure mode as item-invoice types (Sales/Purchase/Credit Note/Debit Note) — symptom is a blank EXCEPTIONS:1 with no useful error text (the real cause, 'Voucher No. is missing', only shows in Tally's own Import Data UI). If creation fails this way, pass voucherNumber explicitly (check get_vouchers for the next free number of this voucher type).

Update an existing Delivery Note in TallyPrime, replacing its item lines, party, and narration. Same fields as create_delivery_note, plus voucherNumber. Matched by date + voucher number — use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique. Refuses if another voucher type shares the same number on that date (confirmed live: Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one) — resolve the collision in Tally first if that happens.

Create a Receipt Note in TallyPrime — an item-line inventory voucher recording goods received from a supplier before or without a full Purchase invoice (e.g. against a Purchase Order). Same item-line shape as create_purchase_invoice (stock item, quantity, rate, Purchase ledger per line) but ISINVOICE is set to No and there's no VAT/tax line — mirror of create_delivery_note on the buying side. Same caveat as create_delivery_note: the voucher type must be active in the company first, or it won't show up in get_vouchers/delete_voucher until it is. get_ledger_vouchers will still never show it, by design. If creation fails with LINEERROR 'Voucher date is missing' even though the date field is set correctly, the date is outside Tally's active period (Alt+F2) — call set_period to cover it and retry (confirmed live).

Update an existing Receipt Note in TallyPrime, replacing its item lines, party, and narration. Same fields as create_receipt_note, plus voucherNumber. Same matching/collision caveats as update_delivery_note.

Create a Sales Order in TallyPrime — a future commitment to sell, before any goods move or invoicing happens. Same item-line shape as create_sales_invoice/create_delivery_note but VCHTYPE is 'Sales Order' and Tally classifies it as an Order-class voucher, structurally different from Delivery Note's inventory-class. Follow up with create_delivery_note (dispatch) and/or create_sales_invoice (billing) against the same party once goods actually move. Same voucher-type-active prerequisite as create_delivery_note (confirmed live) — check it's on in the company before relying on this. orderNumber and each item's dueDate are REQUIRED (unlike other item-invoice tools, where the equivalent fields are optional): confirmed live that Tally rejects an Order-class voucher with 'Order No. is missing in Item Allocations' and separately 'Due Date of Order is missing in Item Allocations' without them. Reverse-engineered from a real manually-created Sales Order's own export: the UI's 'Order no.' field is backed by the voucher-level REFERENCE tag (independent of the voucher number — the real example had voucherNumber '1' and Order no. '12345' as genuinely different values), while the per-item Order No. and Due Date both live nested inside each item's BATCHALLOCATIONS.LIST, not as direct ALLINVENTORYENTRIES fields as their names might suggest. Also confirmed live: Tally silently reassigns its own voucher number for Order-class vouchers regardless of an explicit voucherNumber passed in (its 'Auto Retain' numbering style for this voucher type) — check the actual assigned number via get_vouchers after creating one, don't assume the value you passed was used.

Update an existing Sales Order in TallyPrime, replacing its item lines, party, order number, and narration. Same fields as create_sales_order (orderNumber and each item's dueDate still REQUIRED), plus voucherNumber to locate the existing voucher. Matched by date + voucher number — use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique. Refuses if another voucher type shares the same number on that date (confirmed live: Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one) — resolve the collision in Tally first if that happens. Note voucherNumber here is the existing voucher's own number to match by — Tally may still not let you change it, since Order-class vouchers use 'Auto Retain' numbering (see create_sales_order).

Create a Purchase Order in TallyPrime — a future commitment to buy, before any goods move or invoicing happens. Same item-line shape as create_purchase_invoice/create_receipt_note but VCHTYPE is 'Purchase Order' and Tally classifies it as an Order-class voucher. Follow up with create_receipt_note (goods in) and/or create_purchase_invoice (billing) against the same party once goods actually arrive. Same voucher-type-active prerequisite as create_delivery_note (confirmed live). orderNumber and each item's dueDate are REQUIRED — same reasoning as create_sales_order: reverse-engineered from a real Sales Order export, confirmed the same live errors and Auto Retain numbering behavior apply here too.

Update an existing Purchase Order in TallyPrime, replacing its item lines, party, order number, and narration. Same fields as create_purchase_order, plus voucherNumber. Same matching/collision caveats as update_sales_order.

Create a Job Work In Order in TallyPrime — used when this company is the job worker, booking an order to process raw materials a customer will supply, into a finished item the company will deliver back. Each item line is the finished item expected to be delivered eventually, plus a nested list of components — the raw materials the customer is expected to supply for that item. Reverse-engineered from a real manually-created Job Work In Order's own export (same technique used for Sales Order): the component list lives nested two levels deep, inside each item's own order allocation (VOUCHERCOMPONENTLIST.LIST inside BATCHALLOCATIONS.LIST inside ALLINVENTORYENTRIES.LIST), each component carrying its own nested BATCHALLOCATIONS.LIST with a PARENTITEM back-reference to the item it belongs to. Confirmed live: this structure creates cleanly (no VAT/tax lines, no per-item ledger allocation — just the one balancing party ledger entry for the total). Same voucher-type-active prerequisite as other Order-class vouchers, and orderNumber + each item's dueDate are REQUIRED (same reasoning as create_sales_order). Distinct from create_job_work_out_order, which is for the opposite direction (sending materials out to a job worker).

Update an existing Job Work In Order in TallyPrime, replacing its item lines (and their component lists), party, order number, and narration. Same fields as create_job_work_in_order, plus voucherNumber. Matched by date + voucher number — use get_ledger_vouchers or get_vouchers first to confirm it exists and is unique. Refuses if another voucher type shares the same number on that date (confirmed live: Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one) — resolve the collision in Tally first if that happens.

Create a Job Work Out Order in TallyPrime — used when this company is the principal, sending raw materials out to a job worker (subcontractor) and expecting a finished item back. Mirror image of create_job_work_in_order: each item line is the finished item expected to be received from the job worker, plus a nested list of components — the raw materials this company will send out for that item. Same nested XML structure as create_job_work_in_order, with the accounting direction flipped (matching the existing Sales-side vs Purchase-side sign convention already used by create_sales_order vs create_purchase_order in this connector) since this voucher represents an inward expected receipt rather than an outward delivery. Confirmed live: creates cleanly with no exceptions. Same voucher-type-active prerequisite and required orderNumber/dueDate as create_job_work_in_order.

Update an existing Job Work Out Order in TallyPrime, replacing its item lines (and their component lists), party, order number, and narration. Same fields as create_job_work_out_order, plus voucherNumber. Same matching/collision caveats as update_job_work_in_order.

Create a Sales Quotation in TallyPrime — a pre-order price quote to a prospective customer, one step before create_sales_order. Same item-line shape as create_sales_order, including the same orderNumber (REFERENCE) and per-item dueDate requirements — confirmed live that Tally classifies Sales Quotation as an Order-class voucher (PARENT 'Sales Order' in get_voucher_types) and rejects it the same way without them. Same voucher-type-active prerequisite as create_delivery_note. Follow up with create_sales_order once the customer accepts.

Update an existing Sales Quotation in TallyPrime, replacing its item lines, party, order number, and narration. Same fields as create_sales_quotation, plus voucherNumber. Same matching/collision caveats as update_sales_order.

Create a new account group in TallyPrime, nested under a parent group, or rename/reparent an existing one by passing oldName.

Create a new Stock Group in TallyPrime, nested under a parent stock group. Distinct from create_group (account groups like Sundry Debtors) — this is the category stock items are filed under (create_stock_item's 'group' field). Required before creating a stock item under a brand-new category that doesn't exist yet.

Create a new Unit of Measure in TallyPrime — a simple unit (e.g. 'Kg', 'Box', 'Ltr') by default, or a compound unit (e.g. 'Box of 12 Nos') by passing baseUnit/additionalUnit/conversion. Required before creating or invoicing a stock item in a unit that doesn't exist yet — stock item/invoice tools fail with 'Unit does not exist!' otherwise. For a compound unit, both baseUnit and additionalUnit must already exist as simple units first (confirmed live pattern: create both simple units, then the compound unit referencing them). A simple unit's symbol (and baseUnit/additionalUnit, since those reference existing simple units' symbols) cannot contain whitespace — confirmed live: Tally rejects that with 'Master name contains invalid characters', checked client-side before this ever reaches Tally. A compound unit's own display name (e.g. 'Box of 12 Nos') can still contain spaces.

Create a new Godown/Location in TallyPrime, optionally nested under a parent godown (e.g. a sub-location under a main warehouse). Required before referencing a godown that doesn't exist yet on an invoice/voucher line — those fail with 'Godown does not exist!' otherwise. Pass the parent's plain name, not a dotted path (confirmed live: 'MAIN LOCATION.DUBAI' is invalid, 'MAIN LOCATION' as parent + 'DUBAI' as name is correct).

Create a new Cost Category in TallyPrime (a grouping of cost centres, e.g. 'Branch', 'Project'). Required before creating a cost centre under a category that doesn't exist yet.

Create a new Cost Centre in TallyPrime (e.g. a department, branch, or project used to tag voucher entries for cost tracking — see create_voucher's costCentre fields).

Create a new custom Voucher Type in TallyPrime (e.g. 'Bank Payment' as a sub-type of 'Payment', with its own numbering series/abbreviation) — or rename/reconfigure an existing one by passing oldName. Base types to derive from: 'Payment', 'Receipt', 'Journal', 'Contra', 'Sales', 'Purchase', 'Credit Note', 'Debit Note', 'Stock Journal', 'Physical Stock', etc. — must be an exact existing voucher type name (check get_voucher_types first). Setting numberingMethod explicitly is useful given the confirmed-live issue where some Tally configurations stop auto-numbering item-invoice-mode voucher types via the XML gateway unless a voucherNumber is supplied on every create call — see create_sales_invoice's voucherNumber note. Confirmed live separately: a brand-new custom voucher type created WITHOUT numberingMethod set can accept vouchers with a completely blank voucher number (not even '1') — pass numberingMethod: 'Automatic' explicitly to avoid ending up with unreferenceable vouchers you can only look up/delete by date.

Create a new stock item in TallyPrime

Update an existing stock item in TallyPrime — same fields as create_stock_item, all optional except name.

Delete a stock item from TallyPrime. Fails if it has transactions posted against it. If deleting a voucher that used this item in the same turn, delete the voucher first and confirm it succeeded before calling this — doing both in parallel can race (confirmed live). If this item was used in both a Sales AND a Purchase item-invoice, it may return 'Cannot be deleted!' even with zero balance and no transactions left — fixed by Company Data → Rewrite in Tally itself (confirmed live), not by retrying.

Attach a Bill of Materials (recipe) to an existing finished-goods stock item, so a Manufacturing/Stock Journal producing this item can have its component quantities computed from a fixed ratio instead of typed by hand every time. Uses Tally's native MULTICOMPONENTLIST.LIST structure. This is a pure convenience layer over create_stock_journal — it does not affect stock or post anything by itself; you still call create_stock_journal to actually record a production run, scaling each component's qty by the ratio to basicQty yourself (this tool does not auto-compute that scaling for you). EXTRAPOLATED from a genuine Tally-exported XML template's stock item master shape, not reverse-engineered from a real manually-created BOM — verify carefully after use, especially natureOfItem's accepted values.

Update an existing voucher in TallyPrime, replacing its ledger entries and narration. The voucher is matched by type + date + voucher number, so that combination must be unique and must exactly match an existing voucher (use get_ledger_vouchers or get_vouchers first to confirm it). Either pass debitLedger/creditLedger/amount for a simple 2-leg voucher, or pass 'entries' for 3+ lines, same as create_voucher. Refuses if another voucher type shares the same number on that date (confirmed live: Tally's Alter lookup ignores voucher type and can silently corrupt the wrong one) — resolve the collision in Tally first if that happens.

Permanently delete an existing voucher from TallyPrime — removes it entirely with no trace (distinct from cancelling, which keeps it visible but marked Cancelled). The voucher is matched by type + date + voucher number, so that combination must be unique and must exactly match an existing voucher (use get_ledger_vouchers or get_vouchers first to confirm it). This has no undo. Refuses if another voucher type shares the same number on that date (confirmed live: Tally's lookup ignores voucher type and can silently target the wrong one) — resolve the collision in Tally first.

Pull ledgers, groups, and stock items from TallyPrime into this session's SQL cache (in-memory — gone when this session ends, and replaced whenever you switch company and re-sync, so nothing lingers between different companies), so query_sql can run fast arbitrary queries without hitting Tally each time. Does NOT sync vouchers — use sync_vouchers_to_sql for those, one date range at a time.

Pull voucher HEADERS (date, type, number, party ledger, amount, narration — not line items) for one date range into this session's SQL cache (in-memory, gone when the session ends), so query_sql can aggregate/report on them (e.g. sales by customer by month) without re-fetching from Tally. Call this once per chunk to build up full multi-year history for the CURRENTLY OPEN company within this session — re-running for the SAME range just refreshes it (safe to re-run), and each call only touches vouchers within its own date range, so calling it for 2024 then 2025 gives you both, not just the latest. If you switch companies (set_company), sync again — the cache doesn't track which company a row came from, so don't query across a company switch without re-syncing first. IMPORTANT: pick a chunk size that won't time out — a full year (~7,500 vouchers here) took ~6s against the 10s request timeout; prefer quarterly or monthly chunks for a busy company, and back off further if a call times out. Does not include stock item / ledger line detail (see get_ledger_vouchers/get_vouchers for that).

Pull voucher INVENTORY LINE ITEMS (stock item, qty, rate, amount, godown, batch — one row per item per batch allocation) for one date range into this session's SQL cache, so query_sql can compute movement analysis, godown-wise stock, or batch detail directly. This is the raw data those analyses need — Tally has no exportable 'Movement Analysis'/'Stock Ageing Analysis'/'Godown Summary' report reachable over the gateway (confirmed live against all 138 registered report names, and confirmed live that per-godown $ClosingBalance/SVGODOWNNAME scoping doesn't work either), so this connector doesn't try to replicate those as report tools — pull the line items with this, then write the aggregation as SQL. qty/amount are UNSIGNED as Tally stores them on the inventory entry; use is_deemed_positive together with voucher_type to work out inward vs outward direction. A voucher with no stock items (Payment, Journal, etc.) contributes zero rows, not an empty one. Same chunked, additive-by-date-range model and same timeout caution as sync_vouchers_to_sql — quarterly/monthly chunks for a busy company. If you switch companies (set_company), sync again — the cache doesn't track which company a row came from, so don't query across a company switch without re-syncing first.

Run a read-only SQL SELECT query against this session's in-memory cache (gone when the session ends). Tables: ledgers(name, parent, closing_balance, trn, state, country), groups(name, parent), stock_items(name, parent, closing_balance), vouchers(guid, date, voucher_type, voucher_number, party_ledger, amount, narration), voucher_items(voucher_guid, date, voucher_type, voucher_number, stock_item, qty, rate, amount, is_deemed_positive, godown, batch) — all five populated only by explicitly calling sync_to_sql/sync_vouchers_to_sql/sync_voucher_items_to_sql first. Movement analysis, godown-wise stock, and batch/ageing detail are just SELECTs over voucher_items — there is no separate report tool for them. profit_and_loss(ledger_name, group_name, closing_balance, period_from, period_to), stock_summary(name, parent, opening_qty, closing_qty, opening_value, closing_value, as_of_date), balance_sheet(group_name, amount, as_of_date), trial_balance(name, debit_amount, credit_amount, period_from, period_to), and vat_summary(ledger_name, category, closing_balance, period_from, period_to) are populated automatically, no separate sync step — every get_profit_and_loss/get_stock_summary/get_balance_sheet/get_trial_balance/get_vat_liability_summary call refreshes its table with that call's result, so a follow-up question about the same report can query it here instead of re-fetching from Tally. Each of these five only ever holds the most recent call's data, not a history — re-call the report tool if you need a different period. set_company automatically empties every one of these tables when the active company changes, so a query never silently returns a previous company's rows — it just means every table is empty again right after switching, until re-synced/re-fetched.

Read this connector's append-only audit log — every tool call made through it (read or write), with timestamp, arguments, outcome (success/error/denied), and a best-effort Tally company tag. Entries older than 90 days are permanently deleted (checked once per server startup, not kept indefinitely) — this is not a full historical record beyond that window. Use this to review what an agent actually did against this Tally company, e.g. before trusting a session's claimed results, or to hand a reviewer a plain record of every write made in a given period.

Check whether this connector is actually safe and working right now: is Tally's gateway reachable, is a company open (and which one), what TALLY_URL it's talking to, whether read-only mode is on, and which tools (if any) are explicitly disabled. Use this before trusting a session, or when something feels off, instead of inferring connector state from a single tool call's success/failure.

Build the exact XML for any write tool WITHOUT sending it to Tally — nothing is touched. Returns a previewId plus a plain-English description and the raw XML, so you (or whoever's reviewing) can see precisely what would happen before it happens. Use this instead of calling a create_*/update_*/delete_* tool directly whenever you want a human to review a batch of changes first — e.g. drafting several vouchers from a folder of client documents, where posting the wrong one is costly. Every applicable safety check this tool would normally run (e.g. the voucher-type collision check on update_*/delete_voucher) runs now, at preview time, so the preview already reflects any refusal. A preview expires after 15 minutes and is single-use — call confirm_write with its previewId to actually post it, or just don't confirm it if it's wrong. Never touches Tally with a write of its own (a create_* preview makes no gateway call at all; an update_*/delete_* preview only makes the same read-only collision-check query that tool would normally make) — so unlike every other write tool, preview_write still works even when read-only mode is on. confirm_write is the one that's actually blocked by read-only mode.

Post a previously-built preview to Tally — this is the only tool that actually writes, when the batch went through preview_write first. Takes the previewId from a prior preview_write call and sends that exact XML, unchanged, to Tally. A previewId can only be confirmed once — reusing an already-confirmed or expired one fails rather than silently reposting or reusing stale data.