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.

Return Tally's own Cash Flow for whole months: its month-wise movement of the cash and bank ledgers, not a cash flow statement under AS 3. The months are returned only after the net total of the whole period has been compared with the trial balance, over the ledgers this check counts as cash and bank (those under Cash-in-Hand and Bank Accounts, a group inside them included; a ledger under a group a user made inside one was not measured), and found equal; otherwise the result is not_established and no month is shown (cash_flow_differs_from_trial_balance; cash_flow_money_group_unmeasured when a Bank OD A/c or Bank OCC A/c ledger has movement; cash_flow_nothing_to_compare when neither the cash and bank ledgers nor Tally's Cash Flow carry an amount for the period). Each month's closing is Tally's closing column for it, not checked month by month, and Tally's debit and credit columns are not returned. A month Tally printed with no amount is returned with an empty closing, which is not zero and does not say the month had no entries. A negative amount is a debit: cash and bank grew. The result's unmeasured_in_this_answer names any credit amount, positive closing or window from March into April it contains (a credit amount was seen tied to the trial balance in live runs on one synthetic book (two windows, one of them with a positive closing), and a window from March into April was not run; no month was compared with Tally's own Cash Flow screen: compare such months with it); two zero nets are not a tie (cash_flow_nothing_to_compare). The window must be whole months, at most twelve, and not start before the book (cash_flow_window_not_month_start, cash_flow_window_not_month_end, cash_flow_window_too_many_months, trial_balance_before_books). A book with several currency masters and Education mode are refused. The report's cost on a large book with cash activity is not known (one year of empty months on a large book answered at once): ask for one month first, and if a call times out do not repeat it. 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 three settings Tally's company record holds today for one company: cost centres, GST and batch-wise stock (each yes, no or not_reported), and the company's currency symbol. They say nothing about what the books contain or what the settings were during a year: a cost-centre allocation can be stored while the setting reads No. Each of the three settings has been compared with Tally's own F11 screen, on three synthetic books and not on this company; a setting changed inside a sitting has not been measured. Each setting says what it rests on. The currency is the symbol Tally holds (for example the rupee sign), not an ISO code, and it does not say whether foreign currencies are used. A setting Tally did not send is not_reported, never no. Tally's other feature flags are fetched in the same request and are not returned. Nothing this tool returns changes what another tool reads or refuses. Take company_guid from list_companies. This reads the company record and the book extent twice and returns no ledger, voucher, amount or narration. A company in Education mode is refused. Never present a setting as a fact about the books or about a past period. 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 shorten party and ledger names and bank account numbers or drop narrations, and does not hide amounts, company names, PAN, GSTIN, IFSC, MSME or Udyam registration numbers, contact details or references, or the last four digits of a bank statement's account number (account_last4); under mask_parties a name written inside a narration or reference stays as it is. 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. Use it when the user asks what ComplyEaze Bridge has done, or to show a reviewer which calls ran, on which company and when. Reading the log changes nothing in it; this call's own receipt lines are added after the read, like every call's. 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 Tally's own GSTR-1 status of the vouchers of ONE voucher type in a date window, read from the status flags Tally keeps on each voucher. For each voucher it returns the voucher number, date, voucher type, master_id and alter_id, its gst_status (included, uncertain, excluded, not_in_return, all three flags No, which on the lab's Receipts, read before the request fetched the cancelled, optional and post-dated flags, means Tally does not list the voucher, or cancelled, optional or post_dated, decided first from Tally's own cancelled, optional and post-dated flags and never counted as included, uncertain, excluded or not_in_return; such a voucher's item also holds status_flags, what its three status flags read, which is not counted) and whether a person accepted it as it stands (accepted_as_it_stands, Accept As Is), with the window's counts of each. A status is Tally's own flag and not a judgement of ComplyEaze Bridge: it does not say that a voucher is right or wrong, or that a return is ready to file. The reason for a status is not available: Tally shows it on its screen only, and none is returned. Tally keeps the status a voucher was given when it was saved. included also counts a voucher a person accepted as it stands. post_dated is Tally's flag and not a date still ahead: the lab's one post-dated voucher was marked so by hand and dated the day Tally's current date (set with F2) had been set to, and whether Tally lists a cancelled voucher anywhere in the return, or a post-dated one while Tally's current date is before the voucher's date or once it has reached it, is not measured. A total of 0 may mean the type name matched nothing, and each page is a new read, so a voucher saved between two pages can shift the offsets. A voucher whose flags, or whose cancelled, optional or post-dated flag, are absent or not in a form that was measured, or whose deleted flag reads Yes (never seen: the lab's one deleted voucher left the answer), is returned as unread with a code, never as included, and the result is then partial. Limits: one voucher type by its exact name (a type of the same class under another name is not read), at most 93 days, and a book whose voucher mark is above 25,000 is refused. Measured on one synthetic book of TallyPrime 7.1 Silver only, for the unregistered buyer of its Sales invoices; a registered buyer, other releases and Gold are not measured, and excluded has not been observed. Take company_guid from list_companies and the type name from masters. This first reads the book's voucher mark and then the vouchers of the type in the window, and returns no amount, party or narration. 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, each with its 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 (the optional as_of, YYYYMMDD or YYYY-MM-DD such as 20260331, else this computer's date; without fields=compliance, as_of is refused as ledger_masters_as_of_requires_compliance), taken from the ledger's dated registration history, or from the flat GSTIN field only when that history is empty or not returned (an empty flat field names no GSTIN). party_gstin_status: in_force, flat_field, no_gstin_in_force (a history with no GSTIN in force on that date; party_gstin_registration_type says whether that entry is registered), not_reported, or history_unreadable, which fails closed (an undated, misdated, malformed, repeated or contradictory history: party_gstin is null and the flat field unused). party_gstin_flat is always the flat field as read; gstin_sources_disagree is true when it names a GSTIN the in-force 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 compliance.gst_registrations. Duty head (compliance): gst_duty_head is recognized (head: cgst, igst, state_tax, sgst_utgst, ut_tax or cess; 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, kept apart: to sum state tax, include both. Ancestry (compliance): chain (nearest group first, each hop's name and reserved_name), complete (true only if resolved to the reserved account root) and gap (null when complete, else why it 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 starting with U+FFFD #4; is a Tally reserved value (written ); U+FFFD#4; Primary is the account root, not 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 anywhere 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. A group filter reads the group collection (one more paired read with fields=basic) and returns group_filter: excluded_subgroup_ledgers (count left out for sitting under a sub-group of group, always 0 under ancestry scope, with group_count and up to 20 of those sub-groups in groups) and unresolved_ancestry_ledgers (ledgers not returned whose chain stops short of group, so whether they belong under it is unknown; counted over the whole book). GST details (compliance, opt-in): include_gst_details (a boolean, default false; with any other fields it is refused as ledger_masters_gst_details_requires_compliance) adds compliance.gst_details to each ledger: observation is not_observed (Tally returned no such list), entries (each dated entry with applicable_from, taxability, source, itc_eligible and states; each state row has state_name, slab_rates_present and rates with duty_head, valuation_type and a rate whose kind is absent, empty, zero or value with raw as sent and decimal; other_content_skipped says content was not read) or unreadable (a defect for this ledger only). absent, empty, zero and value mean different things and are never merged. These are Tally's ledger-level details as sent: HSN/SAC and type of supply are not returned because no capture shows them, the place of supply is in the registration history, and slab rates are only flagged. Measured on one 14-ledger lab book of TallyPrime 7.1 Silver; this was not yet run through this tool on a live Tally. Without the flag every request and result is unchanged and carries no gst_details. The read is admitted at 8,000 bytes a ledger instead of 3,750, a margin over the one capture (a ledger with an empty list 2,138 to 2,704 bytes; one dated entry 5,248 to 5,394; UTF-16 bytes of the ledger's own element), not a measured ratio; a large book may be read in more parts or refused as too large. 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 counted ledger must come back exactly once, or the whole call is refused. Above a mark of 22,857 the count runs in AlterID-span slices of at most 4,000, one GUID-only request each; above 400,000 the call is refused before any ledger read (cause ledger_catalogue_too_large, with size), even for a company with fewer ledgers. 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. A size refusal refuses again on retry; 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 exceeds the census's), retry once while the book is quiet; for ledger_count_company_invalid (that count's answer was damaged) or ledger_count_company_response_too_large, retry once, then use fields=basic. A counted read reports ledger_count_cross_check.status: matched, company_count_lower, or unavailable (no count in Tally's answer, so no check ran). Currencies (compliance): a book with several Currency masters is read through the base Tally identifies: only plain base-currency ledgers are returned (ledgers_scope base_currency_ledgers_only); ledgers kept in another currency (foreign_currency_ledgers_excluded) and base-currency ledgers whose balances Tally shows in another currency (base_currency_ledgers_mixed_excluded) are named, never read. Paging: offset 0 always reads Tally afresh and holds the read; later pages are served from it while the book extent, ALTMSTID and ALTVCHID included, is unchanged, and each result reports snapshot. Pass the first page's snapshot_id on later pages to be refused as listing_snapshot_changed (cause book_changed_since_first_page or snapshot_not_held) rather than continue from a different read. With fields=compliance, repeat the first page's as_of: 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 if it names the snapshot; the same holds for include_gst_details: a later page called without include_gst_details reads afresh and returns rows without gst_details (snapshot.reused false), and only a call that names snapshot_id is refused. A change that moves neither mark is not seen, so a later page can be up to 10 minutes old; every screen action measured so far moved one (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). For what parties owe or are owed now, by their open bills, use outstandings 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 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. A slow read says so in the result's read_cost: the window is read twice, a planned read and a replay that proves nothing moved, and the block gives both reads' observed seconds, a floor derived from the census gaps (not measured) and whether those two voucher reads together stayed inside the one measured host limit (the two ledger catalogue reads, the company check and the wider read an empty window gets are not in it); it adds no request and refuses nothing. For every ledger's balances from Tally's own Trial Balance, without reading vouchers, use trial_balance 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.

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 (not_settled_binding_refused: native posts whose binding to their own vouchers was refused, including one Tally rejected in part or whole; they stay not settled for good, their vouchers may or may not be in the book, and the person checks them in Tally. not_settled_no_response, not_settled_binding_refused and not_settled_not_verified do not overlap), 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, the skipped-rows file agent-import-statement-skips.jsonl and the imports folder are ComplyEaze Bridge's memory of what it already sent to Tally and of the statement rows it was told to skip: 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 the numbering value Tally reports at the type level (see below: it is not their numbering method), active and optional flags and series_numbering (the numbering method, under Automatic its sub-method, and the duplicate setting of the type's series), godowns, units (with decimal places and whether simple), stock groups, cost centres (with their category), cost categories (with three allocation flags), 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) and series_numbering ({"observation":"observed","method":"automatic"|"manual"|"automatic_manual_override"|{"unrecognised": <raw text>},"duplicates":"prevented"|"not_prevented"}, with "sub_method":"auto_retain"|"auto_renumber"|"absent"|{"unrecognised": <raw text>} under automatic and under no other method, {"observation":"series_count","count":n} when a type has no series or several, and nothing is read from it, or {"observation":"field_invalid","code":...}), read from a second paired read of the voucher-type export and joined to each row by GUID with the name as a second equality, so a type on one side only, or a GUID and name that disagree between the two reads, refuses the whole read (masters_numbering_names_differ for a type in one read only, masters_numbering_identity_differs for a GUID and name that disagree), as do masters_numbering_collection_changed (the numbering read changed between its two reads) and masters_bound_premise_violated (the numbering answer's row count or size), and a moved book is reported as masters_extent_changed in place of a join or premise refusal; units carry decimal_places and simple; cost centres carry category (always present: a centre without one is refused), cost categories allocates_revenue, allocates_non_revenue and affects_stock; cost centres and categories are returned whether or not the company's Cost Centres setting is on (a book with the setting off was read with its centres, and a book with it on with its own), an empty cost-centre list does not say whether the feature is off or none is defined, and an empty cost-category list is refused (masters_cost_categories_empty, on the expectation that the predefined Primary Cost Category always exists), and ComplyEaze Bridge does not return how a voucher was allocated to a cost centre. 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, stock groups, cost centres and cost categories 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, 1,160 for stock groups, 1,037 for cost centres and 1,264 for cost categories. 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 godowns, units and stock groups (cost centres and cost categories were not tried on them); 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, and their second, numbering read is likewise sent with no size check). 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 (cost centres: three synthetic books, the third captured in a separate sitting whose own status read recorded TallyPrime 7.1, licence Silver, Education mode off; cost categories: two): the type-level numbering_method it carries is not the voucher type's numbering method: it read None for types a person had set to Automatic and to Manual on the screen, and the method is kept per number series, which series_numbering returns instead, so no value of numbering_method (default, automatic, manual or any other) says how a post is numbered. series_numbering was measured on one synthetic book (TallyPrime 7.1 Silver, Windows): 24 voucher types, each with one series named Default, of which three (Journal Automatic, Payment Manual with duplicates prevented, Receipt Manual with duplicates not prevented) were checked against Tally's screen; Automatic (Manual Override) through this tool (it is mapped from the series text measured on a synthetic book on 13 October 2026), more than one series, Multi-user Auto, a single series not named Default, a voucher type created new and other releases were not measured, an unrecognised method is never manual, and the integrated read, the two requests sent as one tool call, was run live on two synthetic books on 14 October 2026 and returned the numbering set or checked on Tally's screen for six types. sub_method is the series' own NUMBERINGSUBMETHOD (auto_retain is the screen's Retain Original Voucher No., auto_renumber its Renumber Vouchers, absent a series that printed none, and any other text, a blank one included, is returned raw under unrecognised); a Manual series printed Auto Retain too, which is not the numbering in force there, so it is not returned for one. It was measured on a second synthetic book (TallyPrime 7.1 Silver, Windows) and one voucher type, Receipt, set to Renumber Vouchers and back: with it on Renumber Vouchers, numbers already in the book changed, at the switch, when a voucher with an earlier date was entered by hand, and when one was sent by import without a number (the import's answer reported nothing altered and no voucher's AlterID moved); any other wording, a series that prints no sub-method, other voucher types, a batch of several vouchers, Gold, other releases and the same through ComplyEaze Bridge's own post are not measured. A value other than Automatic, Manual or Default is returned raw under unrecognised, 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, stock-group, cost-centre and cost-category names, their parents and a cost centre's category are masked, because a job-work godown, a supplier-named stock group or a customer-named cost centre 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.

Return Tally's own month-wise Sales Register or Purchase Register for whole months, read by its report name: one row per month with Tally's debit, credit and closing columns exactly as Tally printed them. The rows are not tied to the vouchers, to the trial balance or to the sales_register and purchase_register tools; on the one synthetic book read, the Sales Register's credit was the month's sales invoices, tax included, and its closing a running total printed only for the months with sales, and the Purchase Register's debit was the month's purchases as a negative amount. The period must be whole months, at most twelve, and must not start before the book does. An empty amount is not zero. The result's limitations say what has not been measured. 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. For a ledger's master record (its group, opening balance and, with fields=compliance, GSTIN and party details), use ledger_masters 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), returns reference_date only when the voucher carries one, as Tally sent it (reference likewise; measured on one synthetic book, on one Purchase), 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 for every book that has held a voucher, however few), 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, or as voucher_window_part_not_admitted when the window was counted. A sgst_utgst head is a state-side head that a consumer summing state tax must include alongside state_tax. Not measured: a REFERENCEDATE on a sale, 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 shorten party and ledger names and bank account numbers or drop narrations, and does not hide amounts, company names, PAN, GSTIN, IFSC, MSME or Udyam registration numbers, contact details or references, or the last four digits of a bank statement's account number (account_last4); under mask_parties a name written inside a narration or reference stays as it is. 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. Use it to check which reads ComplyEaze Bridge made since it started, with their fingerprints and byte counts. It reads memory only; this call's own record is added to memory after the read, and its receipt lines go to the local log, like every call's. 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), returns reference_date only when the voucher carries one, as Tally sent it (reference likewise; measured on one synthetic book, on one Purchase and not on a sale), 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 for every book that has held a voucher, however few), 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, or as voucher_window_part_not_admitted when the window was counted. 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: 102 requests on a book with 8 ledgers and one currency (96 were recorded before a small book was counted, plus the six the count adds; not measured since), 118 on one with 44 ledgers and two currencies, which adds 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; a REFERENCEDATE on a sale; 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.

Tie the bank ledger in Tally to the bank statement already parsed by parse_bank_statement, at the start and at the end of the statement's own dates, or of the whole calendar months it was parsed for. Read-only: it writes nothing to Tally and never posts. Its check of the import journal takes the shared import-admission lock for a moment, so a build or post at the same time can be refused as lock-busy, and it can be refused by theirs; call again. It reads the proposals file named by proposals_id and proposals_sha256 (as build_import_xml does) and the book's ledger list three times: at the window's first date, at the day after its last date, and at the first date again, which catches a change dated before the window or an edit to the ledger itself (its opening balance, name or removal) made during the read (a voucher dated inside the window and posted during the read moves only the end figure and is not caught). No ledger is read when the file alone answers (window_not_recorded, window_narrower_than_statement, window_not_whole_calendar_months, window_beyond_statement_rows) or the window starts before the company's books begin (window_precedes_books_from). It reads no vouchers, and each ledger-list read has the same deadline and size limits as ledger_movement's. The proposals file is not bound to a company: pass the company_guid of the company the statement belongs to, because a different company that has a ledger of the same name is read just as readily. The window is the whole statement, from its first to its last row date, at the balances you supplied. A file parsed with from or to that left rows out is compared over those dates only if they are whole calendar months (from the 1st to a month's last day) within the statement's rows; the opening and closing are then worked out from the statement's own rows, so a gap together with the book's figure gives the statement's balance at the month edge. Any other window is not_established: window_not_whole_calendar_months, or window_beyond_statement_rows when a month starts before the statement's first row or ends after its last. So is a narrowed file written before parse_bank_statement recorded a window's balances (window_narrower_than_statement), and one written before it recorded the statement's dates (window_not_recorded); parse the statement again. The result carries the stage, the two dates, rows_without_voucher, three figures, a fixed reading and the company block. opening_gap is the book at the start of the window's first date less the statement's balance then; closing_gap is the book at the end of its last date less the statement's balance then, where stage before_build adds what this file's vouchers would put into the bank ledger (where the book would stand once the file is imported) and stage after_post is the book as it stands now; change_in_window is closing_gap less opening_gap. All three are in the statement's sign: positive means the book shows more money in the bank than the statement does. The book's own balances are not returned, but a gap plus the statement's balance at that date (for the whole statement, the balance you supplied) gives the book's balance, so they are derivable from the result. For whole calendar months the reverse also holds: the book's figure less a gap gives the statement's balance at the month edge, and change_in_window with the book's movement gives the statement's net over those months. These are totals per calendar month, never a part of a month except the part-months at the statement's own start and end, whose net a month edge's balance gives together with the opening and closing you supplied; but a month in which every other row's amount is already known (one row alone, or one row beside open cash lines, whose amounts parse_bank_statement returns) gives that row's amount. Each figure has a state: tied (exactly zero), differs, or not_established with a reason (window_not_recorded, window_narrower_than_statement, window_not_whole_calendar_months, window_beyond_statement_rows, window_precedes_books_from, bank_ledger_not_in_book, book_changed_during_read; for before_build also rows_without_voucher, when some rows of the statement have no voucher in the file because a cash line is unanswered or a row is skipped, and file_already_partly_posted, when the import journal already holds a row of this file, either of which leaves closing_gap and change_in_window not established). A gap does not say why: uncleared cheques and deposits in transit, a missing entry, a repeated entry and the wrong bank ledger look alike here, and the reading says so and prescribes no remedy. It checks the bank ledger only; a wrong party or expense ledger is not caught. Use it after parse_bank_statement and before build_import_xml with stage before_build, and again with stage after_post after a post or an import by hand. Requires one observed INR currency master, as ledger_movement does. Not yet proved against a live book. 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. A closing quantity is returned only where Tally's own plain Stock Summary shows the same item by name with the same quantity, unit and amount (closing.quantity.state agreed, with amount and unit); every other item says why not (none_sent, unread, inside_stock_group, report_has_no_line, report_name_not_unique, report_differs). In the captures the report listed only what sits directly under the root, so an item inside a stock group is taken to have no line and no quantity is returned for it (inside_stock_group); totals.closing_quantity_unread_count counts quantities 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, checked_per_item or not_checked: the closing-value total is checked; the closing quantity is checked item by item; 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 exactly as Tally sends it, and quantity (a state, with amount and unit when it is agreed). 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. For one ledger's movement counted from the window's vouchers, with how many vouchers touched it, use ledger_movement 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.

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 Tally then gives vouchers keyed again the post's MasterIDs, GUIDs and numbers, so a bound voucher can read posted_verified while being one keyed by hand with the same content: measured once, bridge#1050. In plain words: after a restore, a native voucher keyed again with the same content before any check can read verified, and no identifier a read returns tells the two apart (measured once on TallyPrime 7.1 Silver, with Tally's security off), so after restoring a backup over a company, check its posted vouchers in Tally), 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 has since become the batch's current proof, with verification_proof_altered if the saved proof no longer matches its recorded SHA-256, and with verification_too_large_to_report if the parts never cut do not fit the response cap. The first page also carries a transfers section for the company, in the shape build_import_xml returns: the bank rows skipped as carried by another account's Contra that are not yet paired with a verified Contra, by bridge_txn_id and date. It is computed after the verdict is saved and changes no verdict; transfers.state not_established means it could not be computed (for example another process holds the import folder) or was cut to fit the response, not that nothing is open. A later page never carries it. Every verification's full proof is kept on disk; none is replaced. Reads the batch's date window from Tally, then adds new proof files for the batch beside every earlier one and a status record naming them current, and may also add 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, replacing and deleting nothing there (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; ComplyEaze Bridge makes that count for every book that has held a voucher, however few, so a small book can read complete too. A nonempty window not counted is partial with reason nonempty_window_unqualified. An empty window is complete only when a read widened by a day on each side is also empty and the company has no vouchers (company_has_no_vouchers); it is otherwise partial, with empty_uncorroborated when the widened read is also empty but the company has vouchers, and empty_window_wider_read_nonempty when the widened read found rows on the neighbouring days, which cannot count the window. 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. A proposal comes back absent only when the window is proven complete, nothing in it resembles the proposal, a voucher type declared manual carries its voucher number, and the party was supplied and could be compared completely; a proposal with no party (a Journal has none), no manual number, or a party whose comparison was cut short comes back possibly_present with a reason such as party_not_supplied, manual_number_not_supplied or party_not_decidable, however complete the window is. 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. To list the vouchers of a date window, use vouchers 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.

Say, before a call, the most census reads one call of vouchers, ledger_movement or verify_import will send on this company (a read can be refused before its census ends), and the least time a call that is not refused earlier spends on the gaps between them. The census follows the company's voucher mark, not the window: this figure is for one call, a narrower window does not lower it, and reading N days in N calls pays it N times. It is as of this call's own read of the mark; the next call reads the mark again. It reads the company's identity and then its marks (one paired read with an identity check on either side), the opening every windowed call makes, and sends no census and no voucher request. The count and the floor are derived from the mark and the gate's rules, not measured on this book, and the floor leaves out every data part. No estimate is made: measured is constant text, whole calls recorded in the protocol reference with their census reads, data parts, host, date and confidence, each marked as not a bound. Nothing is refused on this figure; the one refusal it can state is the one the read itself makes (voucher_window_book_too_large). 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, search and grouping, 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, a read widened by a day on each side was also empty, and the company has no vouchers (reason company_has_no_vouchers); otherwise it is partial, with reason nonempty_window_unqualified when rows were not counted, empty_uncorroborated when an empty window's widened read is also empty but the company has vouchers, and empty_window_wider_read_nonempty when the widened read found rows on the neighbouring days (the window's own read found nothing and those rows cannot count it, so an empty window beside a busy day cannot reach complete today). ComplyEaze Bridge makes that count for every book that has held a voucher, however few, so nonempty_window_unqualified is expected only when the company's mark reads zero while the window holds rows. 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: Tally asserts it on every voucher when the fetch list asks for it, and the key is left out only when a source does not report it (one old capture did, taken before the tag was asked for), so it is boolean only when Tally asserted Yes/No and 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's listing 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. (A summarise_by call is the exception: it sets aside cancelled, optional and entry-less vouchers and counts them, and sums post-dated ones with a count.) 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. Search: voucher_number and reference (each matched whole, ignoring ASCII case and surrounding spaces), narration_contains (a phrase of at least 3 characters, matched ignoring letter case, accent composition and runs of spaces) and amount (a plain unsigned decimal, matched against the absolute value of any ledger entry of a voucher, so it finds an invoice total and a tax line alike) keep only the vouchers that satisfy every criterion given. The search runs last, on the labelled window, so a zero from a complete window is a checked zero; each item then carries matched (which criteria held and, for an amount, the positions in amounts that equalled it). A blank, over-long or invalid criterion is refused (search_criterion_empty, search_criterion_too_long, search_narration_too_short, search_amount_invalid), and a narration phrase is refused as search_narration_redacted where narrations are withheld from the assistant. suspense_tagged (true, only with ledger) keeps the vouchers of that ledger whose narration ends in a suspense tag ComplyEaze Bridge writes and says which in matched.suspense_tag; it classifies by the narration text, so the same text typed by hand matches and a narration edited after the tag is not listed: also read the ledger without it. It is refused as search_suspense_tagged_needs_ledger without ledger and as search_narration_redacted where narrations are withheld. A voucher withheld for a foreign-currency amount is never dropped by an amount search, since its amounts cannot be compared: it stays in withheld_vouchers and the result stays partial. A held window is reused only for the same search, and only for the same listing or summary: a listing and a summary of one question hold separate windows. voucher_types counts are taken before the search, so with a search they do not add up to total. Summaries: summarise_by (ledger, month, voucher_type, group or primary_group) returns buckets instead of items, over the same window and the same selectors and search; offset and limit then page the buckets. Each bucket has group (a ledger name, a YYYY-MM month, a voucher type name or a group name), vouchers (an exact count, each voucher once), debit (zero or negative, as ledger_movement reports it), credit, net (debit plus credit) and voucher_refs (up to 5 vouchers by date, type, number and GUID; voucher_refs_complete says whether that is all of them; a vouchers listing without summarise_by, narrowed with the existing selectors, lists the rest). Debit and credit follow each entry's sign (a zero amount stays on the side Tally flagged it). A ledger bucket adds the entries on that ledger of the vouchers the window, selectors and search selected: with a ledger, type or search given, a counter-ledger's bucket holds only its entries on those vouchers, not that ledger's whole movement. A month or type bucket adds all the entries of its vouchers (debits and credits then equal in size), or only the selected ledger's entries when ledger is given. entries_counted says which: all_entries or selected_ledger. A group or primary_group bucket adds the entries of the ledgers under that group (every entry of the selected vouchers, also when ledger is given). A group bucket holds only the ledgers directly under that group, as the ledger master shows it (a ledger directly under the root is under Primary, with reserved_name null), so a predefined group whose ledgers sit in sub-groups has no bucket or a small one: its whole figure, descendants included, is in subtree_totals (each group on any bucket's chain with covers, depth, vouchers, debit, credit and net over everything under it, never to be added to a bucket of the same group, whose own covers says it holds only the ledgers directly under it, largest movement first, at most 60, with subtree_totals_total exact and subtree_totals_complete; they overlap, so they do not add up to totals). A group bucket carries reserved_name (empty for a group the book's user made), chain (every group from it up to the one under the root, nearest first, each with name and reserved_name) and primary_group. A primary_group bucket holds every ledger under the group directly under the root and is keyed by its reserved name, so a renamed predefined group stays one bucket and shows its current name in group (a group the book's user made there is keyed by its name). Each has members (the ledgers in it with their own debit and credit, largest movement first, at most 10), members_total (exact) and members_complete; a group bucket cannot be narrowed with a selector, so trace its vouchers through a member ledger with ledger. Group names are shown as the book has them (a group may be named after a party); member ledger names are masked when parties are masked. The groups are the book's masters read now, not the grouping in force on each voucher's date: each ledger's group chain is read before the window and again after it and must be the same, or the call refuses (group_snapshot_drifted, or ledger_snapshot_drifted if the set of ledgers changed). A ledger that the ledger list does not hold, or whose group chain cannot be walked, refuses the whole summary (summary_group_unresolved, with cause no_parent, group_absent, group_name_repeated, reserved_name_missing, cycle, exhausted, top_group_not_under_root or ledger_not_in_catalogue; ledger names the ledger that could not be placed, the group is not named, and no_parent also covers a parent group Tally returned that ComplyEaze Bridge will not carry). By construction a group summary adds 30 requests to the window read, with or without ledger (a paired, identity-bracketed read is 6 requests: the company's marks to size the ledger list first, then the ledger list and the group list before the window and again after it); in one live run each call took 64 requests (34 for the window and 30 for the group modes, as counted from the code); a book of thousands of ledgers was not measured: a book whose master-alteration mark is above 11,983 is refused first (summary_group_book_too_large; the limit is provisional and computed, not measured: 16 MiB, a size chosen here and not verified, over the compliance ledger read's estimate of 1,400 bytes a ledger, which that read measured at 1,104 (a book of 1,989 ledgers) and 1,221 (a real book of about 9,500) on its own list without balances, and this list read 1,175 bytes a ledger in one live run (51,698 bytes for a book of 44 ledgers; a small book, so the figure is not a basis to raise the limit); the mark is an upper bound on ledgers, so a smaller book may be refused, and the limit is about half of what the transport's own rule admits for the same list), a real book's group buckets may need several pages (use offset), and on a large book ledger totals are cheaper with trial_balance. Group summaries were checked once against a live TallyPrime 7.1 on one synthetic book of 67 vouchers: each bucket equalled the ledger buckets added up by the trial balance's own parent column and the call took 64 requests; a large book, a group renamed or moved while a window is read and a held later page were not run live. Each bucket has position, its place in the whole ordering (labels of ledgers can read alike when parties are masked, and a masked label cannot be passed back as ledger); to list a month bucket's rest, narrow from and to to that month. totals is the debit and credit the buckets add up to, vouchers_summarised the vouchers behind them, and excluded_from_buckets the cancelled, optional and entry-less vouchers left out (counted, not hidden). Post-dated vouchers are summed, not set aside: post_dated_included counts those Tally flagged Yes and post_dated_flag_absent those with no flag at all (the read asks for the flag and Tally asserts it on every voucher, so that is expected to be 0; only when it is not does a zero in the first prove nothing); a voucher type that does not post (a memorandum, a reversing journal, a sales or purchase order, a delivery or receipt note), if the book uses it and Tally exports it with ledger entries, is not told apart and is summed too: basis says so in the result. Checked once against a live TallyPrime 7.1 on a synthetic book of 67 vouchers (a year, 44 ledgers, a debug build of master at 4c30f3f9f): every ledger, month and voucher-type bucket equalled the sums over the listed vouchers, the 30 ledger buckets equalled trial_balance for the same year, each search returned what the same criterion selects from the listing, and a later page came from the held window in 10 small requests. Not covered: a memorandum, a reversing journal, a voucher withheld for a foreign-currency amount, mask_parties, withheld narrations, an item invoice with stock lines, paging of a summary past one page, ledger name resolution, another TallyPrime edition or release, Windows, a large book. Cost, from that one run: a plain read took 34 requests, about 7 s and about 6 MB from Tally; each ledger, month or voucher_type summary or search call reads the window again at the same cost, and ledger adds 12 requests there, four of them reads of the whole ledger list (a group summary adds 30 with or without ledger, below); for a month or more on a large book read ledger totals with trial_balance (it has no month or voucher-type grouping and no search; the same year's trial_balance took 34 requests and 2.5 s on that book; one day of vouchers took minutes on the largest book measured, a voucher mark of about a million). Bucket debit, credit, net and totals are plain decimals with trailing zeros dropped (1000, -87900.5); an item's amounts keep the two places Tally sent (1000.00). Withheld vouchers are not in any bucket and the result is partial. A voucher whose entries do not balance refuses the whole summary (voucher_entries_unbalanced). Buckets are ordered by the larger movement first (ledger, type, group, primary_group), ties in movement keeping the order in which the bucket was first counted in the window, or by month. A held window serves a later page of buckets as it serves a later page of vouchers. Each ledger entry's bill_allocations carries reference, bill_type and amount; where Tally sends them it also carries bill_date (YYYYMMDD, the original bill's date for an Agst Ref) and credit_period (a value and a unit of days, weeks or months, or unit unrecognised with its text when the text cannot be read); an allocation Tally sent neither for has neither. To ask whether vouchers you mean to post are already in the book, use voucher_presence 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.