Return the Balance Sheet for a date range, derived from Tally's native Trial Balance: one line per reserved Balance Sheet primary group (Capital Account, Loans (Liability), Current Liabilities, Suspense A/c, Branch / Divisions, Fixed Assets, Investments, Current Assets, Misc. Expenses (ASSET)), each the signed closing balance at to (a debit negative), and result.profit_and_loss: the Profit & Loss A/c ledger's closing and the carried result (that closing plus every P&L ledger's closing; in a part-year window the year's earlier result sits in that ledger). The top-level lines is null while carried is not established, so a derived line is never shown as the statement. Reads the Trial Balance, the group tree and Tally's own Balance Sheet inside one company, mode and book-extent bracket; requires observed INR currency (a book with more than one currency master is refused) and supported date boundaries. Each line reports amount (sum, present_count, empty_count): the sum is over the amounts Tally returned, and the empty ones it left out are counted. A result is established only if every ledger is classified (a ledger under a user-created primary group, or whose group chain is incomplete, is listed in unclassified, up to 100, with unclassified_total), no Stock-in-Hand ledger carries an amount, and Tally's own Balance Sheet for the window ties line for line to the derived one (balance_sheet_gate). Otherwise it is not_established with a reason (unclassified_ledger_carries_an_amount, closing_stock_not_derivable_from_trial_balance, profit_and_loss_ledger_not_returned, tally_balance_sheet_differs, or for gross and net tally_profit_and_loss_differs); for the two differs reasons, lines names the lines that did not tie. The top-level state is observed only while carried is established, and not_established otherwise with the same reason the nested result carries. A book with stock items is expected to refuse; no inventory book has been measured. A Tally line with an amount the derivation has no counterpart for, such as a heading or a difference in opening balances, refuses rather than being guessed at. Tally's own statements carry no company identity and are bound only by the checks around the read. The gate has been measured over one full year on one book and one month on another; a window spanning more than one financial year is unmeasured. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Everything the assistant reads from Tally through ComplyEaze Bridge in this chat, amounts included, is sent to the AI provider; redaction can only mask party names or drop narration. Never tell the user that no data has left their computer. Shows the receipts ComplyEaze Bridge keeps of its own tool calls, read from its local log file on this computer: tool, time, company, counts and fingerprints, no figures or book content (bounded to the most recent receipts). It does not show what the AI provider received. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Return a company's ledger masters with each one's opening balance as of the start of the books (opening_balance, opening_balance_as_of), on a freshly observed supported product and mode. fields=basic (the default) or fields=compliance, which adds paired party-master observations (GSTIN, PAN, MSME, bank, contact and address), each ledger's group ancestry and its gst_duty_head. GSTIN (compliance): party_gstin is the GSTIN in force on party_gstin_as_of, which is the optional as_of (YYYYMMDD or YYYY-MM-DD, such as 20260331 for a year end) or else this computer's date; as_of without fields=compliance is refused as ledger_masters_as_of_requires_compliance. It comes from the ledger's dated registration history, or from the flat GSTIN field only when that history is empty or was not returned; an empty flat field names no GSTIN. party_gstin_status names the source: in_force, flat_field, no_gstin_in_force (a history with no GSTIN on that date; party_gstin_registration_type says whether that entry is registered) or not_reported. history_unreadable fails closed: the history came back undated, misdated, malformed, repeated or contradictory, so party_gstin is null and the flat field is not used. party_gstin_flat is always the flat field as read, and gstin_sources_disagree is true when it names a GSTIN that the in-force history entry does not; both are reported, neither is chosen. For another date, such as a transaction's, pass it as as_of or read the dated entries in compliance.gst_registrations. Duty head (compliance): gst_duty_head is recognized (with head: cgst, igst, state_tax, sgst_utgst, ut_tax or cess, and raw, the spelling Tally returned), unrecognized (raw kept), not_tax_ledger, contradictory or absent. state_tax (raw State Tax) and sgst_utgst (raw SGST/UTGST) are two spellings Tally has returned for a state-side head and are kept as two heads: a consumer summing state tax must include both. Ancestry (compliance): chain (nearest group first, each hop's own name and reserved_name), complete (true only if the chain was resolved all the way to the reserved account root) and gap (null when complete, else why resolution stopped: no_parent, group_absent, group_name_repeated, reserved_name_missing, cycle or exhausted). An incomplete chain is never padded or guessed: chain is exactly what was resolved, so check complete before treating it as exhaustive. A reserved_name beginning with U+FFFD #4; is a Tally reserved value (Tally writes it as ); U+FFFD#4; Primary is the account root, distinct from a group a user named Primary. Group filter: group filters by group name. group_scope "immediate" (the default) matches only the ledger's own parent and does NOT include ledgers under sub-groups of group; "ancestry" matches any group in the resolved chain, the whole subtree (a ledger under Bank OD A/c matches Loans (Liability)), with either fields value, and a gap in a chain never counts as a match. Any group filter reads the group collection (with fields=basic, one added paired read), and the result carries group_filter: excluded_subgroup_ledgers (count of ledgers left out because they sit under a sub-group of group, always 0 under ancestry scope, with group_count and up to 20 of those names in groups) and unresolved_ancestry_ledgers (ledgers not returned whose chain stops before reaching group, so ComplyEaze Bridge cannot say whether they belong under it; counted over the whole book, so a gap anywhere is counted). Large books (compliance): when the master-alteration mark (an upper bound on the ledgers, since every master raises it) puts the estimated response over budget, the ledgers are counted first, then read whole or, if the count does not fit, in parts by parent group; every ledger counted must come back exactly once, or the whole call is refused. Above a mark of 22,857 the ledgers are counted by AlterID span, in slices of at most 4,000, one request each for GUIDs only. Above 400,000 the call is refused before any ledger read, with cause ledger_catalogue_too_large and size, so a company with fewer ledgers may be refused. Each refusal names its cause: parent_over_budget, parent_partition_too_many_parts, parent_complement_over_budget, ledger_without_parent, parent_name_unsupported (with unsupported_parent_ledgers), parent_partition_duplicate_ledger_identity, the parent_part_* coverage causes, parent_part_response_too_large, ledger_span_slice_over_bound, ledger_span_duplicate_identity, ledger_span_census_empty, ledger_span_slice_malformed, ledger_span_identity_mismatch, ledger_span_slice_response_too_large or ledger_count_catalogue_too_large. Retrying a size refusal refuses again, and fields=basic still reads the book. For ledger_count_differs (two counts, or a count and the ledgers read, disagree) or ledger_count_company_differs (Tally's own ledger count is higher than the census's), retry once while the book is quiet; ledger_count_company_invalid means that count's answer was damaged, and ledger_count_company_response_too_large that it was larger than the response limit: retry once, then use fields=basic. A counted read reports ledger_count_cross_check.status: matched, company_count_lower, or unavailable when Tally's answer carried no count, so the check did not run. Currencies (compliance): a book with several Currency masters is read through the base Tally identifies: its plain base-currency ledgers are returned with ledgers_scope base_currency_ledgers_only, and the ledgers kept in another currency (foreign_currency_ledgers_excluded) and the base-currency ledgers whose balances Tally shows in another currency (base_currency_ledgers_mixed_excluded) are named, never read. Paging: a first page (offset 0) always reads Tally afresh and holds the read; a later page is served from it while the book extent, including ALTMSTID and ALTVCHID, is unchanged, and each result reports snapshot. Pass the first page's snapshot_id on later pages to have the call refused as listing_snapshot_changed instead of continuing from a different read (cause book_changed_since_first_page, or snapshot_not_held for an id not held). With fields=compliance, repeat the first page's as_of on later pages: a snapshot serves only pages read as of the same date, so a later page without it (or across midnight) reads afresh, or is refused when it names the snapshot. A change that moves neither mark is not seen. Each screen action measured so far moved a mark (a regroup, an opening change, a ledger create or delete, a voucher delete, a cancel, a save with no change; protocol reference section 11c.5, one run each), but a change that moves neither can leave a later page up to 10 minutes old. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Return literal-window ledger opening, exact debit/credit movement, closing, and touched-voucher count with a freshly observed supported product/mode and an operation-valid opening boundary. Reads the full voucher window before filtering or pagination; use narrow dates. Dense windows can fail source limits. Requires one observed INR currency master: a book with several Currency masters, none, or one that is not INR is refused before any ledger read. A ledger name resolves only when spelled as in the book or differing from it only in ASCII case and spaces; ledger_match names the ledger read, how (matched: exact, or case_or_spacing, which the answer should mention by naming the ledger read) and any similar_ledgers that differ from it only in case or whitespace. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Start here. Return observed company tuples (the company_guid every tool that reads a company's books needs) and identity ambiguity flags. If exactly one company is open and the user named no client, use it and say which in your first line; if the user names a client and exactly one open company matches that name, use it and say which; otherwise ask which, offering the list, and never guess a company. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Reports what ComplyEaze Bridge stores locally, by class, with counts, sizes, the age of the oldest file and the state of its import journal: how many batches were sent or found posted, how many of those are not settled, and how many have no recorded dispatch and were never verified as posted (no_dispatch_never_verified: this can include a batch imported by hand, which may be in Tally, so never treat it as proof that a batch is absent). Reads ComplyEaze Bridge's own local data folder and the per-user folder of dispatch lease locks (names, sizes and times) and names no file path. A folder, link or journal it could not read or enter is reported as such (incomplete_reason and folders_that_could_not_be_listed, and this call's evidence is partial), never as empty or absent. It covers the folder the MCP server and the desktop Journal flow share; the desktop app's other settings, its mirror database and logs live elsewhere and are not covered. The import journal and the imports folder are ComplyEaze Bridge's memory of what it already sent to Tally: never suggest deleting them. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

List a company's masters of one kind: voucher types with their numbering method (Automatic, Manual or Default, as Tally reports it) and active and optional flags, godowns, units (with decimal places and whether simple), stock groups, or account groups (groups). Each row of another kind carries name, guid, master_id, alter_id and parent (null where it does not apply or is absent; a parent that is Tally's reserved root is written as U+FFFD #4; Primary, as in the group tree); a groups row carries name, parent and reserved_name only. Voucher types also carry active, optional (true, false or null when Tally did not say) and numbering_method (automatic, manual, default, {"unrecognised": <raw text>} for any other value Tally reports, or null when absent); units carry decimal_places and simple. One kind per call, read inside one company, mode and book-extent bracket: the extent before and after must be equal and each collection is read twice and compared, so a book that changed during the read is refused. Whole reads only. Godowns, units and stock groups are read only when the book's master-alteration mark times an assumed worst-case row for that kind fits 16 MB (the mark counts the masters of every kind, so a book with few of this kind can be refused), and otherwise refuse before any request with masters_too_large and size (master_alter_id, estimated_bytes, limit_bytes, limit_master_alter_id); that admits marks up to 1,152 for godowns, 1,168 for units and 1,160 for stock groups. Retrying refuses again. The refusal's size carries limit_master_alter_id, the largest mark this kind is read at. Both stock-heavy client books measured, with marks of about 100,000 and 300,000, refuse these three kinds; how common such marks are across live books is unmeasured. voucher_types and groups have no size check before the read (voucher types keep the policy of ComplyEaze Bridge's other voucher-type read). After a read of any kind other than groups, each row's length is checked against the assumed worst-case row (masters_row_exceeds_bound), and the row count, the rows' AlterIDs (at or under the mark, none repeated) and the response size (each collection is read twice, and the size check runs after both reads) are checked against the mark and the admitted size; a breach of those three refuses the whole read as masters_bound_premise_violated and returns no partial list, unless the closing extent shows the book moved, which is reported instead (masters_extent_changed). A response ComplyEaze Bridge cannot read refuses at once with a masters_* cause, and a voucher_types answer with no rows refuses as masters_voucher_types_empty, because every company has predefined voucher types. Not returned: alias names, counts and hints (no company NUM* fields), stock items, ledgers (use ledger_masters), and any write. The row shape was captured from one synthetic book on one licensed TallyPrime 7.1: Default, Automatic and Manual are the only numbering methods seen, and any other value is returned raw, not refused. default is Tally's reported value, not evidence that a type numbers automatically. The company's voucher-type count (NUMVOUCHERTYPES) did not equal the rows returned on two books (35 vs 26, 33 vs 24), and on one book equalled the number-series count (inferred to count series, unmeasured), so do not check these rows against it. The completeness of the voucher-type list is unverified: absence from it is not evidence that a voucher type is absent from the book. Under mask_parties, godown and stock-group names and their parents are masked, because a job-work godown or a supplier-named stock group can carry a party's name (Tally's reserved root as a parent is left as it is). Voucher-type, unit and account-group names are not masked: they are configuration labels, not counterparties. Education mode is refused. A first page (offset 0) always captures a fresh read and holds it in memory; a later page for the same kind (offset > 0) is served from it while the company's book extent, including ALTVCHID and ALTMSTID, is unchanged, at the cost of one small extent read. Each result reports snapshot (id, master_alter_id, voucher_alter_id, read_at, reused). Pass the first page's snapshot_id on later pages to have the call refused with listing_snapshot_changed (cause book_changed_since_first_page or snapshot_not_held) instead of continuing from a different read. A change that moves neither mark is not seen, so a later page can be up to 10 minutes old after such a change. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Answer what is outstanding: receivable and payable totals from Tally's own paired bills reports, ageing, the top parties and the open bills, on a freshly observed supported product and mode and a date valid for the operation. as_of is optional: left out, it is this computer's date (tally_status today), and the date used is always returned as result.as_of, whatever the state. top ranks parties only; page the bills with offset and limit. open_bills_total counts every open bill in the requested direction, all of which totals and the ageing cover, and open_bills_shown counts the bills on this page (limit is not lowered when the response size shortens the page): when shown is less than total, say so plainly, for example "showing 500 of 1,240 open bills; the totals and the ageing cover all 1,240" (on a later page, the bills from offset + 1; on a partial read, both counts and the sentence cover the base-currency ledgers only, so say so in it), and ask for the next bills with offset set to next_offset. receivable and payable follow the sign of each bill's balance, as Tally's own Bills Receivable and Bills Payable reports scope them, not the type of party: a customer's advance or a credit note raised to a customer appears under payable, and a supplier's advance or a debit note raised to a supplier under receivable, because those reports carry no bill type. That holds for an advance or a note kept as its own bill: an on-account advance goes to the unallocated figure instead, and a credit note set against an open invoice reduces that invoice. Measured on one synthetic book (TallyPrime Silver 7.1). Read a bill's kind as a direction, not as owed by a customer or owed to a supplier. An unallocated amount's direction is the sign of the party's net unallocated balance, so an on-account receipt and an on-account payment on one party net into one figure. A book with several Currency masters is read through the INR base Tally identifies. If it has ledgers kept in another currency (foreign_currency_ledgers_excluded, each with its currency) or base-currency ledgers whose balance Tally shows in another currency (base_currency_ledgers_mixed_excluded, each set aside with all its bills), the state is partial with partial_reason currency_ledgers_excluded and partial_reasons naming the lists that are not empty: figures cover its base-currency ledgers only, under base_currency_ledgers, never a total for the whole book, and both lists are always present, paged like the bills. Each unallocated party carries ledger_bill_wise, opening_balance (the ledger's opening as of the start of the books, with Tally's sign, so a debit opening is negative, never interpreted; absent when Tally sent none, which is unknown, not zero) and a composition: not_bill_wise_ledger (the ledger keeps no bills) or bill_wise_ledger_components_not_separated (what is left on a bill-wise ledger after its named bills: on-account entries, an unallocated opening, notes with no reference and anything else, not told apart). amount is a magnitude and direction says which side; unallocated.totals.by_composition splits the gross, receivable and payable apart, by those two over every party in the requested direction before paging (a row saved without one counts under composition_not_observed). No unallocated figure is labelled on-account. Party detail: with party (a ledger name) and detail, the result also carries a detail object for that party at the same as-of. A ledger name resolves only when spelled as in the book or differing from it only in ASCII case and spaces; the detail's ledger_match names the ledger read, how (matched: exact, or case_or_spacing, which the answer should mention by naming the ledger read) and any similar_ledgers that differ from it only in case or whitespace. Passing detail is the request to read the company's vouchers from the start of the books (or, for a named bill that Tally's bills reports list, from the earliest date they list for it) to as_of; nothing is read for a party detail without it. bill_trail (optionally one reference) lists every allocation of each bill in vouchers that are neither cancelled nor optional, oldest first, with state tied (the signed allocations equal Tally's own balance for that bill, or zero for a bill the report no longer lists), trail_does_not_tie (both numbers shown) or bill_identity_ambiguous (more than one native row or bill date for one reference, or a native row dated differently from the allocations; nothing is merged, and the native dates are shown). Naming a reference starts the read at the earliest date the reports list for it, so allocations dated earlier are not read, and a reference that carries two bill dates over the whole history, and is ambiguous there, can tie when named. The detail's own state is bills_listed, or for an empty list not_bill_wise_ledger or no_named_bill_for_party (no named bill in the vouchers or in Tally's list: a ledger that keeps no bills, one that is not a party's and a party with no bills are not told apart). The vouchers and the bills reports are two reads whose extents are not compared: a voucher posted between them usually shows as trail_does_not_tie, but two changes that compensate, or allocations that net to zero, can still read tied. unadjusted lists the party's on-account, advance and pending note allocations and compares their on-account sum with the party's unallocated amount: tied means the two figures are equal, not that the composition is proven (components that net to zero are not seen); residual_not_explained_by_vouchers gives the difference and whether it equals the ledger's opening balance; no_residual_row_for_party (with residual null) means Tally lists no unallocated amount for the ledger (a zero residual, a ledger that is not a party's and a name that matched no row are not told apart), so nothing is tied; not_bill_wise_ledger lists no rows. Its rows are row_amounts: as_allocated: each amount is the allocation as made, never net of what later allocations adjusted against its reference, so an advance shows what was received, not what is left; what is still open on a reference is Tally's own native_balance beside the row, null when the reports do not list the reference or list it more than once (so no balance is chosen), told apart only by native_rows. Either detail is window_returned_no_vouchers, with nothing tied or listed, when the voucher read returned no voucher (that read is not corroborated). Cost and limits: the detail keeps the party's entries from the whole company's vouchers, so its cost is that of a vouchers read over the same span, which is unmeasured on a large book, and any refusal of that read fails the whole outstandings call. One foreign-currency composite voucher anywhere in the window fails it (voucher_amount_invalid, or bill_allocation_amount_invalid on an allocation). At most 128 data requests are sent (each sent twice, as every read is, with its census and the company marks besides), each holding at most 42 vouchers before anything is measured, so a window of more than 5,376 of the company's vouchers is always refused, and a smaller one may be. The refusals are trail_window_too_large (name a reference that open_bills lists for the party, and the read starts at that bill's date), named_bill_window_too_large (a reference was named already, so nothing narrows it further) and unadjusted_window_too_large (nothing narrows it, so it is not available for that party on that book), each with reads.needed_at_least against reads.allowed; a refusal comes before any data request when the count shows it, otherwise when a measured part does, with window listing any part already read. The detail needs a complete read (detail_requires_a_complete_read, with the read's own partial_reason) and refuses rather than cuts an answer of over 500 allocations: trail_too_large (name a reference) or unadjusted_detail_too_large (nothing narrows it). The limit counts allocations, not bills, so a party with very many opening bills can meet agent_response_too_large instead. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Return the Profit and Loss for a date range, derived from Tally's native Trial Balance: one line per reserved P&L primary group (Sales Accounts, Direct Incomes, Purchase Accounts, Direct Expenses, Indirect Incomes, Indirect Expenses), each the window's signed debit plus credit movement (a debit negative), with gross_result and net_result (a profit positive). The top-level lines is null while net_result is not established, so a derived line is never shown as the statement. Reads the Trial Balance, the group tree and Tally's own Balance Sheet inside one company, mode and book-extent bracket; requires observed INR currency (a book with more than one currency master is refused) and supported date boundaries. Each line reports amount (sum, present_count, empty_count): the sum is over the amounts Tally returned, and the empty ones it left out are counted. A result is established only if every ledger is classified (a ledger under a user-created primary group, or whose group chain is incomplete, is listed in unclassified, up to 100, with unclassified_total), no Stock-in-Hand ledger carries an amount, and Tally's own Balance Sheet for the window ties line for line to the derived one (balance_sheet_gate). Otherwise it is not_established with a reason (unclassified_ledger_carries_an_amount, closing_stock_not_derivable_from_trial_balance, profit_and_loss_ledger_not_returned, tally_balance_sheet_differs, or for gross and net tally_profit_and_loss_differs); for the two differs reasons, lines names the lines that did not tie. The top-level state is observed only while both gross_result and net_result are established, and not_established otherwise with the same reason the nested result carries (the weaker result decides). A book with stock items is expected to refuse; no inventory book has been measured. A Tally line with an amount the derivation has no counterpart for, such as a heading or a difference in opening balances, refuses rather than being guessed at. Tally's own statements carry no company identity and are bound only by the checks around the read. The gate has been measured over one full year on one book and one month on another; a window spanning more than one financial year is unmeasured. Tally's own Profit and Loss is read too and compared by display name in tie_out (matched, matched_empty_as_zero, differs or not_compared). Gross and net are also refused as tally_profit_and_loss_differs unless it ties: no line differs, no derived line is missing from it, and no line of its with an amount is uncompared, except its Cost of Sales : heading while that equals the derived Purchase Accounts plus Direct Expenses exactly (observed once, on one book). A stock line refuses. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Read-only: a register of what the books record, not a GST return. It does not decide input tax credit eligibility or blocked credit, matches nothing against GSTR-2B or any portal, checks no GSTIN (party_gstin is returned only when the voucher carries one), does not return REFERENCEDATE yet (reference is returned only when the voucher carries one), does not classify an item invoice's purchase as taxable (has_taxable_entry is false when no entry sits on a Purchase Accounts ledger), and never sums tax across heads or vouchers. It does not treat reverse-charge journals, imports (IGST paid at customs) or input service distribution specially: a voucher that touches a Duties & Taxes ledger is listed by the rule below and nothing more. A GST duty head does not say whether a ledger is input or output, and a Debit Note can be a purchase return or a debit note issued to a customer: each row carries party_group (the voucher party's predefined group, for example Sundry Creditors or Sundry Debtors, when it resolves) and the tool does not guess which it is. It inherits the compliance read's refusals (an INR base currency is required; a book too large to list is refused; see ledger_masters) and refuses with register_master_mark_unavailable when Tally does not report the master-alteration mark. Each page re-reads the masters and the window, so rows can shift between pages. Return the Purchase and Debit Note vouchers of a date window that touch a ledger under Duties & Taxes, with the tax each entry carries taken only from the GST duty head recorded on that ledger's master -- never from a ledger name and never from an amount. Reads the full voucher window before pagination (use narrow dates) and the ledger masters twice, before and after it. Per row: tax_in_books lists each entry on a ledger whose head ComplyEaze Bridge recognises as {ledger, head, raw_head, amount}; duties_taxes_entries_without_gst_head lists entries on Duties & Taxes ledgers that carry no GST head and never assigns them one: observation not_tax_ledger is a ledger whose own tax type is not GST (usually TDS or another payable), absent is a ledger with no head whose tax type is GST or was not reported, which may be a GST ledger whose head is missing (tax_type says which); duties_taxes_entries_with_unrecognised_head lists entries whose head is not in the recognised vocabulary or contradicts the ledger's tax type, with the raw spelling and its observation; entries_on_ledgers_with_unresolved_group lists entries on ledgers whose group chain could not be resolved; taxable_entries are entries on Purchase Accounts ledgers only (a GST purchase booked to a fixed-asset or expense ledger has has_taxable_entry false); party_entries are the voucher party's own; other_entries is everything else (round-off included) with no role inferred. status is the first that applies of head_conflict, has_unrecognised_head, has_unresolved_group, has_entries_without_gst_head, has_other_entries, complete. The response state follows the rule vouchers uses: complete only when every voucher read was checked against a separate count of the window (a census, which ComplyEaze Bridge sends unless the book's voucher high-water mark alone proves it small, a few dozen vouchers), otherwise partial with reason nonempty_window_unqualified and the rows still returned; an empty window is complete when its corroboration read confirms it. A row's status is separate: it says whether every entry the voucher touches classified, and the state does not change it. Amounts are as the books state them (negative is a debit), never re-signed and never summed across heads; there is no input-credit or direction field. reference, party_gstin, is_invoice, post_dated follow vouchers: absent means not observed, and cancelled, optional and post_dated vouchers are returned flagged, not excluded. Every other voucher type that touches Duties & Taxes (Sales, Journal, Payment and so on) is listed apart in other_voucher_types_touching_duties_taxes, not in items: whether it belongs in a return is the CA's call. A voucher with no resolved class is listed under unclassified_voucher_type; a voucher that touches only unplaceable ledgers under vouchers_with_unplaced_ledgers; a Purchase or Debit Note voucher with no entry on a Duties & Taxes ledger under purchase_vouchers_without_duties_taxes_entry (exempt or unregistered purchases, tax booked to a ledger filed elsewhere, or a cancelled voucher). A cancelled voucher is listed there with cancelled true whether or not it was taxed, because the cancelled vouchers measured came back from Tally with no ledger entries; a cancelled voucher that keeps its entries is not measured. Rows are in items (paged by offset and limit like vouchers); each has has_taxable_entry, false when no entry sits on a Purchase Accounts ledger (an item invoice may hold it in an inventory allocation). The side lists carry exact counts (total) and at most 100 items (listed); every ledger name in the response is masked like vouchers masks it. A voucher that names a ledger the masters do not list, a master or voucher that changed while the window was read, or a ledger set aside for its currency, refuses (ledger_snapshot_drifted, voucher_window_changed_during_read, register_ledger_currency_excluded) and releases no rows; a row dated outside the window refuses as window_not_honoured. A sgst_utgst head is a state-side head that a consumer summing state tax must include alongside state_tax. Not measured: REFERENCEDATE (not returned), item invoices whose purchase ledger sits in an inventory allocation, and books with several currencies. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Everything the assistant reads from Tally through ComplyEaze Bridge in this chat, amounts included, is sent to the AI provider; redaction can only mask party names or drop narration. Never tell the user that no data has left their computer. Shows ComplyEaze Bridge's own recent reads since it started, kept in memory on this computer: request and response fingerprints, byte counts and state, no figures or book content (bounded: the newest limit records). It does not show what the AI provider received. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Read-only: a register of what the books record, not a GST return. It does not decide the place of supply, the tax rate, whether tax is payable or which part of a return a sale belongs in, matches nothing against any portal, checks no GSTIN (party_gstin is returned only when the voucher carries one), does not return REFERENCEDATE yet (reference is returned only when the voucher carries one), and never sums tax across heads or vouchers. It does not treat exports, sales under reverse charge or advances specially: a voucher that touches a Duties & Taxes ledger is listed by the rule below and nothing more. A GST duty head does not say whether a ledger is input or output, and a Credit Note can be a sales return or a credit note issued to a supplier: each row carries party_group (the voucher party's predefined group, for example Sundry Debtors or Sundry Creditors, when it resolves) and the tool does not guess which it is. A Debit Note, including one issued to a customer, is not a sales row: it is listed apart by identity and ledger names, with no amount. It inherits the compliance read's refusals (an INR base currency is required; a book too large to list is refused; see ledger_masters) and refuses with register_master_mark_unavailable when Tally does not report the master-alteration mark. Each page re-reads the masters and the window, so rows can shift between pages. Return the Sales and Credit Note vouchers of a date window that touch a ledger under Duties & Taxes, with the tax each entry carries taken only from the GST duty head recorded on that ledger's master -- never from a ledger name and never from an amount. Reads the full voucher window before pagination (use narrow dates) and the ledger masters twice, before and after it. Per row: tax_in_books lists each entry on a ledger whose head ComplyEaze Bridge recognises as {ledger, head, raw_head, amount}; duties_taxes_entries_without_gst_head lists entries on Duties & Taxes ledgers that carry no GST head and never assigns them one: observation not_tax_ledger is a ledger whose own tax type is not GST (usually TDS or another payable), absent is a ledger with no head whose tax type is GST or was not reported, which may be a GST ledger whose head is missing (tax_type says which); duties_taxes_entries_with_unrecognised_head lists entries whose head is not in the recognised vocabulary or contradicts the ledger's tax type, with the raw spelling and its observation; entries_on_ledgers_with_unresolved_group lists entries on ledgers whose group chain could not be resolved; taxable_entries are entries on Sales Accounts ledgers only (a sale booked to another ledger, or whose sales ledger sits in an inventory allocation, has has_taxable_entry false); party_entries are the voucher party's own; other_entries is everything else (round-off included) with no role inferred. status is the first that applies of head_conflict, has_unrecognised_head, has_unresolved_group, has_entries_without_gst_head, has_other_entries, complete. The response state follows the rule vouchers uses: complete only when every voucher read was checked against a separate count of the window (a census, which ComplyEaze Bridge sends unless the book's voucher high-water mark alone proves it small, a few dozen vouchers), otherwise partial with reason nonempty_window_unqualified and the rows still returned; an empty window is complete when its corroboration read confirms it. A row's status is separate: it says whether every entry the voucher touches classified, and the state does not change it. Amounts are as the books state them (negative is a debit), never re-signed and never summed across heads; there is no input-credit or direction field. reference, party_gstin, is_invoice, post_dated follow vouchers: absent means not observed, and cancelled, optional and post_dated vouchers are returned flagged, not excluded. Every other voucher type that touches Duties & Taxes (Purchase, Journal, Payment and so on) is listed apart in other_voucher_types_touching_duties_taxes, not in items: whether it belongs in a return is the CA's call. A voucher with no resolved class is listed under unclassified_voucher_type; a voucher that touches only unplaceable ledgers under vouchers_with_unplaced_ledgers; a Sales or Credit Note voucher with no entry on a Duties & Taxes ledger under sales_vouchers_without_duties_taxes_entry (listed by identity only; the tool does not say why such a voucher carries no tax entry). A cancelled sale that Tally returns with no ledger entries is listed there too, with cancelled true; no cancelled sale has been read, so whether one keeps its entries is not measured. Rows are in items (paged by offset and limit like vouchers); each has has_taxable_entry, false when no entry sits on a Sales Accounts ledger (a sale typed on Tally's screen, or an item invoice of another shape than the imported one that was measured, may hold the sales ledger in an inventory allocation instead; not measured). The side lists carry exact counts (total) and at most 100 items (listed); every ledger name in the response is masked like vouchers masks it. A voucher that names a ledger the masters do not list, a master or voucher that changed while the window was read, or a ledger set aside for its currency, refuses (ledger_snapshot_drifted, voucher_window_changed_during_read, register_ledger_currency_excluded) and releases no rows; a row dated outside the window refuses as window_not_honoured. A sgst_utgst head is a state-side head that a consumer summing state tax must include alongside state_tax. Measured so far: sales_register was run against a live Tally on two synthetic companies. On the first, once per day, for one taxed Sales item invoice and one untaxed one: the taxed sale came back as one row with its CGST and SGST/UTGST heads taken from the ledger masters and its sales ledger as the taxable entry, and the untaxed one (read once by an earlier build; its voucher window is committed, its masters and the tool's answer are not) was counted under sales_vouchers_without_duties_taxes_entry. On the second, which has 44 ledgers, for one Credit Note in voucher view booked on account: one row, with its CGST and state-tax heads and its sales ledger as the taxable entry. One Sales accounting voucher (not an invoice) was also classified, in tests, against the ledger masters of the purchase register's lab book. A Credit Note is returned as a row with its signs reversed as Tally sends them: the tool neither nets nor flips, so a caller that sums tax over a window must add signed amounts. The measured Credit Note of 1,000.00 with 90.00 CGST and 90.00 State Tax came back with the sales entry -1000.00, each tax entry -90.00 and the party entry 1180.00, where a Sales row has the sales and tax entries positive and the party entry negative. The state-side tax head is state_tax (raw State Tax) on one measured book and sgst_utgst (raw SGST/UTGST) on another; both are recognised heads for the same side of the tax, so a caller must not look for one of them only. The cost of a call varies by book: 96 requests on a book with 8 ledgers and one currency, 118 on one with 44 ledgers and two currencies, which adds a voucher census and base-currency reads; the result does not report the cost. Not shown by any run: an invoice-view Credit Note; an inter-state (IGST) line; a cancelled or optional sales voucher; an unrecognised or missing duty head on a sale; more than one voucher in a window; paging; a company with a registration; a tax that Tally computes itself; a sale typed on Tally's screen; accounting-invoice mode; a post-dated sale; a REFERENCE or a populated PARTYGSTIN on a sale; REFERENCEDATE (not returned); and a ledger or voucher kept in a currency other than the book's base. A row of such a kind is returned, not withheld, and carries not_measured_live naming why (invoice_view_credit_note, inter_state_line, sales_ledger_not_an_entry, cancelled, optional, post_dated, party_gstin_present, reference_present) only where the row itself shows the kind. Kinds a row cannot show are never marked and are not vouched for: a sale typed on Tally's screen in voucher view, a tax Tally computed itself, a duty head no sales capture has (such as cess), an invoice of another shape than the one run (for example several goods lines), and a ledger or voucher kept in a currency other than the book's base; an unmarked row is not a measured one in those respects. A row is marked inter_state_line only when a tax entry's ledger master carries a recognised IGST head; an IGST ledger with no head, or an unrecognised head, is listed under the without-head or unrecognised list and the status is not complete. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Return the stock summary: the closing stock value per stock item as of a date, with the total of those values checked against Tally's own Stock Summary, and whether inventory is integrated with the accounts. The top-level state is one of three. value_total_matched: the items are returned, and their closing values add up to the sum of the top-level lines of Tally's own Stock Summary; only that total was compared, so value_total_matched can stand beside partial true when some items have no closing value. no_stock_items: Tally's own stock item count is 0, the item list is empty and the Stock Summary is empty; items is an empty list. not_established: no item is returned (items is null), reason says why and remediation says what to do next: tally_stock_summary_differs (the report has a total the items do not add up to), tally_stock_summary_shows_no_value (the items carry a value and the report has no amount; an empty report is not told apart from one Tally did not render) or stock_values_not_comparable (nothing could be compared). Such a result carries unchecked_comparison in place of tie_out, for investigation only: neither side is a stock value or a total, the items' side adds only the closing values present, and the closing-value total of a matched read is the only thing this tool checks. A not_established result is not held for paging, and it replaces any earlier read of the same date. Quantities are withheld: nothing checks them, so none is returned; totals.closing_quantity_unread_count counts those that could not be read (a compound unit, or a unit with a space), which do not refuse the read. checks says per field what is checked, not_checked or withheld: the closing-value total is checked; each value on its own, the names, parents and base units, and whether the date was honoured are not. as_of (YYYYMMDD or YYYY-MM-DD) must be a 31 March, not before the book's start or after today. The only period measured is the period ending 31 March 2026; other years' 31 March are admitted but unmeasured, and any other date is refused as stock_summary_as_of_not_measured before any request. The period runs from 1 April (or the book's start, if later) to as_of. Each item carries name, guid, parent, base_unit and closing; closing holds value only, exactly as Tally sends it. Empty is not zero: an empty closing value is returned as null and counted in totals.empty_closing_value_count, and a value sent as 0.00 is a value. Signs are kept, as in the trial balance: a negative value is a debit, which is stock held, and Tally's own Stock Summary screen shows it as a positive value (measured on one synthetic company, licensed TallyPrime 7.1 Silver). value_sum adds the values with their signs, so stock held gives a negative sum, and totals.value_sum_signs is always as_sent_negative_is_debit; value_sum is written at the scale of the values it adds, and is null with partial true whenever any item's closing value is empty. The opening quantity and value are read but not returned, because their as-at date is unmeasured. inventory reports integrated, inventory_on and batchwise as yes, no or unknown (unknown does not refuse), and basis states what Tally reported (ISINTEGRATED); how the books use these values (as closing stock, or against a Stock-in-Hand ledger) is not measured. An item valued at zero or with no value adds nothing to either total, so only Tally's own stock item count vouches for it; that count followed the one delete measured (one synthetic company, one sample), which is not proof of a complete list (checks.item_list_complete is not_checked). item_count_cross_check reports rows, tally_count and status: items are returned only when the two are equal. Otherwise the read is refused as stock_summary_item_count_differs (both numbers under counts); a count Tally did not give refuses as stock_summary_read_failed with cause stock_item_count_unavailable, and a Stock Summary this Tally does not recognise with cause stock_report_unknown. items (1 to 50 GUIDs, each once) filters what is returned from the held read; a GUID not found is listed under items_not_found, not refused, and totals, tie_out and item_count_cross_check still cover the whole book. The inventory flags, the stock items and the Stock Summary are each read twice inside one company, mode and book-extent bracket, or the read is refused. A book whose inventory is off is refused as stock_not_enabled, Education mode is refused, and a company split by year, whose sibling companies share the GUID, is refused (stock_summary_read_failed, cause company_flags_not_one_row). Small books only: the items are read whole only when the master-alteration mark (it counts masters of every kind) times an assumed worst-case row fits 16,000,000 bytes, a mark of at most 874; a larger book is refused before any item request as stock_summary_too_large, with size, and retrying refuses again. Typical stock-heavy client books refuse today. A row count or response size past what was admitted refuses as stock_summary_bound_premise_violated, or stock_summary_extent_changed if the book moved. Limits: company totals only, with no godown or batch split and no rates. The row shape and the tie were measured on one synthetic book on one licensed TallyPrime 7.1 (the tie also once on a client book); other releases, dates and books are not measured. An item's name and parent are masked under mask_parties, because stock names can carry a customer's or supplier's name (Tally's reserved root as a parent is left as it is); guid is not masked and is what items filters on. A first page (offset 0) always reads afresh and holds the read; a later page for the same date is served from it while the book extent, including ALTVCHID and ALTMSTID, is unchanged, and each result reports snapshot. Pass the first page's snapshot_id on later pages to have the call refused as listing_snapshot_changed instead of continuing from a different read (cause book_changed_since_first_page, or snapshot_not_held for an id not held). A change that moves neither mark is not seen, so a later page can be up to 10 minutes old after such a change. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Return loopback endpoint status and observed loaded-company identity tuples. Every ComplyEaze Bridge process on this computer (the desktop app and each AI client) sends to one Tally port one request at a time. Any tool that reads may therefore refuse, having sent nothing: tally_endpoint_busy when another ComplyEaze Bridge window or AI client held the port for longer than this call's bounded wait (about 10 seconds in all per call); it carries retry_after_s, and the same call is safe to repeat after that many seconds. post_import can be refused the same way, but only repeat it when the refusal says attempt_recorded is false; once an attempt is recorded, follow the refusal's next_step (verify_import) and never call post_import again. tally_endpoint_lock_unavailable when ComplyEaze Bridge could not open its local coordination file. today is this computer's calendar date (YYYYMMDD), the date outstandings uses when as_of is left out, and ledger_masters with fields=compliance for party_gstin. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Return native ledger-wise Trial Balance for a date range, using Tally's TBAL fields without scanning vouchers. Requires an INR base currency and supported date boundaries. A book with several Currency masters is read through the base Tally identifies: only its plain base-currency ledgers are returned, with ledgers_scope base_currency_ledgers_only, the ledgers kept in another currency named under foreign_currency_ledgers_excluded, and the base-currency ledgers whose balances Tally shows in another currency named under base_currency_ledgers_mixed_excluded; totals then cover those plain ledgers only (totals_scope) and are not expected to balance. Preserves empty amounts; paired source stability is not voucher-level reconciliation. Pagination limits output only. A first page (offset 0) always captures a fresh report and holds it in memory; a later page for the same period (offset > 0) is served from it while the company's book extent, including ALTVCHID and ALTMSTID, is unchanged, at the cost of one small extent read. Each result reports snapshot (id, master_alter_id, voucher_alter_id, read_at, reused). Pass the first page's snapshot_id on later pages to have the call refused with listing_snapshot_changed (cause book_changed_since_first_page or snapshot_not_held) instead of continuing from a different report. A change that moves neither mark is not seen. A voucher delete, a cancel, a save with no change and a master change made in Tally's own screens each moved a mark when measured (protocol reference section 11c.5, one run each), but a change that moves neither can leave a later page up to 10 minutes old. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Bind 1–100 nonblank ledger names (at most 1024 characters each) against the live catalogue. An identifier embedded in a master name is matched before the name itself. match_state is exact, identifier, near_miss or missing; folded names remain near_miss candidates because this catalogue has no qualified scope to bind them. Only exact is admitted by build_import_xml, and a bound row alone carries exact_live_spelling. A near-miss is never resolved: it returns candidates with the rule that surfaced each, bounded to 25 names and 8192 UTF-8 bytes per requested name, with candidate_count, candidate_count_is_lower_bound and truncation reported. When candidate_count_is_lower_bound is true, the count is a conservative lower bound and must be shown as at least that many candidates. There is no ranking and no score. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Read back a manually imported local batch and write Proof-of-Post files. This never dispatches import XML to Tally. The result gives verification_status, counts, every voucher that is not posted_verified (unverified_vouchers; for a native post a voucher may be bound_not_in_window, book_rolled_back or sent_not_attributed, never absence, with post_span_binding naming how the post was attributed and a plain summary to give the person first; a book restored from a backup and then keyed past the post's voucher mark before this check is not seen as rolled back, and if Tally then reused the post's MasterIDs a bound voucher could read posted_verified while being another voucher with the same content: unmeasured, bridge#1050), duplicates, unrelated_duplicates_in_window and ambiguous_within_batch in full, never cut to fit. Only the posted_verified vouchers are paged, as items from offset out of verified_total; when the response cap shortens them it sets truncated and next_offset. To read further pages, call again with proof_sha256 set to the returned proof.sha256 and offset set to next_offset: those pages come from the persisted proof and never read Tally again. The call is refused with verification_proof_changed if a newer verification replaced that proof, and with verification_too_large_to_report if the parts never cut do not fit the response cap. The full proof is always written to disk. Reads the batch's date window from Tally, then creates or replaces the batch's saved proof files and saves a status record, and may also save a verified baseline, a masters-check record and, for a native post, the binding of its vouchers to the Tally vouchers its post created, in ComplyEaze Bridge's local folder on this computer (paging an existing proof only reads it); writes nothing to Tally.

Answer which of 1–500 proposed vouchers are already in the book. presence is present, possibly_present or absent, and only present names a book voucher. A nonempty window is read as complete only when its rows were checked voucher for voucher against a count ComplyEaze Bridge made of the window first, as vouchers labels it; otherwise, as on a new or test company with a few dozen vouchers, it is partial with reason nonempty_window_unqualified. An empty window can still be corroborated complete. present and possibly_present never need a complete window and are produced either way, but absent means absent from the whole window and is only ever produced from one proven complete — a proposal that would otherwise be absent from a merely partial window instead comes back possibly_present with reason window_not_proven_complete. The conditional decision basis can use a voucher number on a voucher type you declare manual — unique on both sides, within an observed voucher type, and never onto a cancelled or optional voucher; or, for a voucher ComplyEaze Bridge wrote into a file a person imported by hand, the narration marker derived from the supplied batch_id and bridge_txn_id together. A native post (post_import) writes no marker, so this tool cannot identify its vouchers: one edited or re-dated in Tally can read absent here. Check a natively posted batch with verify_import, which finds its vouchers by the GUIDs its post created once its binding is made, before posting any of them again. It neither accepts nor reads client remote identifiers. Supplying only one narration identity component is an error. The marker reaches only the current writer identity scheme; older-scheme ComplyEaze Bridge writes stay unidentified rather than matched. Date, party and amount only ever produce candidates, with the rule that surfaced each and no ranking or score. Every voucher type a proposal names needs a declared numbering method; under automatic Tally discards the supplied number, so nothing can be decided from it. absent means absent from this window, so cover the dates the book could hold. Reads the full window before comparing; dense windows can fail source limits. Party names bind through the same rules as validate_masters. A reported difference on a present voucher is a finding for a person, not a work item: correcting a voucher by Alter or Cancel silently creates a duplicate instead (§9.7), and no ComplyEaze Bridge path can correct a voucher it did not write. This never dispatches import XML to Tally. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Return the fail-closed local voucher-file schema; no Tally request is sent. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.

Return literal-window voucher evidence with curated metadata and redaction. Reads the full source window before selectors and output pagination; limit does not reduce Tally work. A complete window is held in memory for its later pages: a page after the first (offset above 0) is served from that read, with one marks read instead of the whole window, while the company's two marks (vouchers and masters) are unchanged, and its result carries snapshot (id, master_alter_id, voucher_alter_id, read_at, reused). Pass the first page's snapshot_id on later pages to have the call refused with listing_snapshot_changed (cause book_changed_since_first_page or snapshot_not_held) instead of continuing from a different read. Without it, a later page whose window is no longer held or whose book moved reads the window again, and rows can shift between pages. A partial window is not held. A later page is served only for the same question: the same dates (a date is the same however it is written), the same voucher-type selector and the ledger argument exactly as typed on the first page (a differently spelled ledger is a different question and reads the whole window again). Without snapshot_id, a page whose held window found the book moved reads afresh and carries earlier_snapshot (offsets_do_not_continue true): start again from offset 0. snapshot_id is read on later pages only. Only a page whose snapshot.reused is true continues the earlier pages: a later page with reused false or no snapshot is a fresh read whose offsets may not continue them. A change that moves neither mark is not seen; not established: whether a company feature or configuration change that alters export content moves a mark, whether a restored copy of the company with the same marks is told apart, and whether a remote writer's save shows in the marks at once. So a held page can be up to ten minutes old after its read finished; a first page is always read fresh. Use narrow dates; dense windows are unqualified and can fail source limits. state is complete only when the window's rows were checked voucher for voucher against a count ComplyEaze Bridge made of the window first, or the window was empty and corroborated; otherwise it is partial with reason nonempty_window_unqualified. ComplyEaze Bridge makes that count on every book too large to read whole without one, so in practice only a new or test company with a few dozen vouchers ever reads partial for this reason. Selectors apply after the window is labelled, so a zero from a complete window is a checked zero. A voucher created, altered or deleted between the count and the read refuses with voucher_window_part_not_admitted, cause part_census_mismatch; call again. Each item carries cancelled and optional (always booleans; a source that omits or cannot assert either fails the whole read rather than guess). post_dated behaves differently: a real capture has shown Tally omitting that tag entirely rather than asserting No, so it is boolean only when Tally asserted Yes/No, and the key is absent from the item when Tally did not report it. Absent is not evidence of false — it means ‘Tally did not say’, not ‘Tally said no’, and a caller must branch on key presence, not on falsiness, before treating a voucher as not post-dated. Neither this tool nor voucher_presence filters out post-dated (or optional/cancelled) vouchers; the caller decides what a non-posting or unobserved status means for its own computation. reference, is_invoice and party_gstin follow the same absent-means-not-observed convention as post_dated: each key is present only when Tally reported a non-empty value for it, and its absence must not be read as false or as an empty string. is_invoice is a boolean exactly like post_dated; reference and party_gstin are non-empty strings when present. A captured book with no GSTIN recorded against a party's ledger has shown party_gstin absent on every voucher for that party, which is not evidence Tally cannot report one. Filter by voucher type with at most one of: voucher_class (a reserved class such as Purchase, matched however the book has renamed its types, and including their child types, by Tally's own class functions), voucher_type_guid (exactly one type; a GUID that is not this company's is refused as voucher_type_guid_foreign), or voucher_type (one display name, matched ignoring ASCII case as Tally does). Voucher-type names are editable in Tally, so a display name that is a class name, or the reserved name of any type in scope, is refused as voucher_type_ambiguous whenever the types of that name are not exactly the types of that class or reserving that name; the types involved are listed in candidates (bounded to a quarter of the response budget, with candidates_total and candidates_truncated). Use voucher_class or voucher_type_guid instead. That check sees only the vouchers in scope: the window read, after any ledger filter. A type with no voucher in scope is not seen, and when nothing is in scope nothing is ambiguous. When a voucher_type name selects no voucher, one more read lists the book's voucher types: a name no type carries is refused as unknown_voucher_type, with the name as requested and every type in candidates, nearest name first (bounded as above); a name some type carries keeps its zero. A filtered result carries voucher_types: the types included and every type in_scope (name, GUID, own reserved name, class and row count), and each item carries voucher_type_guid, voucher_type_reserved_name and voucher_class (null outside the measured classes). A row whose type Tally cannot resolve, or whose class answers contradict each other or its reserved name, refuses the whole read. A voucher whose amount Tally stored as a foreign-currency composite (-$ 100.00 @ I₹ 86/$ = -I₹ 8600.00) is withheld, not read: it still passes every date, ledger and type check, and is then listed in withheld_vouchers (GUID, date, type, number and cause foreign_currency_amount_unparsed, up to 100) with an exact withheld_total, the same on every page. items and total then exclude it, state is partial with reason vouchers_withheld, and coverage says so; the voucher_types row counts still include it, and the listing is also bounded to a quarter of the response budget. Any other amount Tally did not return as a plain decimal still refuses the whole read, as does a composite whose foreign and base amounts differ in sign while the foreign amount is not zero. A ledger name resolves only when spelled as in the book or differing from it only in ASCII case and spaces; ledger_match names the ledger read, how (matched: exact, or case_or_spacing, which the answer should mention by naming the ledger read) and any similar_ledgers that differ from it only in case or whitespace. Each call appends metadata-only receipt lines (tool, company, counts, request and response fingerprints; no book content) to ComplyEaze Bridge's local log on this computer; it writes nothing to Tally.