"Yii" matching MCP tools:

• upload_trial_balanceA

  schedule-iiiA

  Stage a Trial Balance spreadsheet (xlsx or csv, max 4 MB) for an entity by INLINING its bytes as base64. This path is ONLY for programmatic callers (a script, Claude Code, an automation) that already have the raw file on disk. If a HUMAN has the file — e.g. they attached it to this chat — do NOT use this tool and do NOT base64-encode the file: call create_upload_link instead and give them the link to upload it in their browser. File size does not change this: even a small attached file goes through create_upload_link — inlining a human-supplied file is unreliable and its bytes routinely truncate. Even for a file you hold on disk, prefer create_upload_link once the file is larger than about 10 KB: base64 through a model context mutates a token often enough that the damage lands as a PLAUSIBLE trial balance, not as an obvious error. VERIFY THE HASH BEFORE YOU CONFIRM ANYTHING: this tool returns received_file_hash, the sha256 of the bytes the server actually received. Compute the sha256 of the file on your disk and compare the two. If they differ, the bytes changed in transit — do NOT call confirm_column_mapping on this session; re-send the file with create_upload_link instead. A mismatched file can still parse cleanly and still show sensible columns, so the hash is the only reliable check. Returns the upload session with detected columns and mapping SUGGESTIONS — nothing is ingested yet. Next: verify received_file_hash, then review the suggested column mapping with your user, then call confirm_column_mapping.

  ConnectorNo auth

• get_tb_rowsA

  schedule-iiiA

  Read the SOURCE DATA behind a statement: the trial-balance rows (account name, debit, credit) as landed for a period, BEFORE grouping — the pre-statement numbers, not statement figures. PREFER FILTERS over fetching everything: name_patterns (e.g. ['cash','bank','od']), side ('debit'/'credit' by net balance), and min_abs_balance return a small exact subset with its own debit/credit totals — e.g. wrong-side cash accounts = name_patterns ['cash','bank'] + side 'credit'. Paginated (page 1-based; page_size default 50, max 500). These are the CURRENT live rows: statement figures are frozen at a generated version, so if the trial balance was re-uploaded after a version was generated, these rows may not tie to that version (the response `note` says so). Amounts are decimal strings in rupees. Figures are Datavrn's deterministic engine output; interpretation is your assistant's.

  ConnectorNo auth

• get_setup_statusA

  schedule-iiiA

  Answer "how do I get started?", "what do I do next?", or help a user who seems lost setting up. Returns where they are in the journey from an empty organization to a finished Schedule III statement, and the ONE next step to take. Call it WITHOUT client_id first (the organization view): it lists the entities this credential can see, or — if there are none — the step to create the first one. Then call it again WITH one entity’s client_id for that entity’s full step-by-step path (upload trial balance → confirm groupings → capture figures → generate → download). Each step has a status (done / next / todo / blocked / web_only) and either the exact tool to call or a web-app link. NARRATE ONE STEP AT A TIME — walk the user through the single `next` step; do not dump the whole list unprompted. Steps marked web_only are done in the Datavrn web app and need a login — never claim you can do them yourself. This tool reports STATUS only (counts, names, what is done) — it never returns a figure or balance; read those with get_statement_figures once a statement is generated.

  ConnectorNo auth

• finalise_statementA

  schedule-iiiA

  Seal a statement version as Datavrn’s permanent client copy, recorded as authorised by the member you name. THIS IS NOT APPROVAL OR ADOPTION OF THE FINANCIAL STATEMENTS AND IT IS NOT A SIGNATURE. It does not discharge section 134(1) for a company or section 34(3) for an LLP. THERE IS NO UNDO. A change afterwards means generating a new version and finalising that one; the version you seal here stays sealed. Call get_finalise_readiness first, show your user every gate and every warning it returns, get their explicit go-ahead, and only then send the confirm_token it gave you together with the acknowledgements. Never acknowledge a warning your user has not seen, and never write the acceptance reason yourself — it is their professional judgment in their own words. Datavrn will refuse if anything about the statement changed after you read the state, and nothing will be finalised. If the response comes back with reused set to true, a finalisation of this same version was already under way: nothing new was done and your approval was not used. Do not call finalise_statement again — the status field says where that finalisation is (queued, running, or paused, which means it hit a temporary problem and Datavrn will retry it on its own). Poll get_job with the job_id and tell your user what it says.

  Connector

  Destructive

  No auth

• assert_previous_year_no_activityA

  schedule-iiiA

  Record your user’s assertion that the previous year genuinely had no activity, so this statement’s all-nil previous-year Profit and Loss is a fact rather than a closing-entry artefact. This clears Datavrn’s refusal to finalise it. THIS IS A PROFESSIONAL ASSERTION ABOUT A CLIENT’S ACCOUNTS, RECORDED IN THE NAMED MEMBER’S NAME AND KEPT WITH THE STATEMENT. Only send it when your user has told you, in their own words, that the previous year had no activity — a dormant entity is the case it is for. NEVER write the reason yourself and never paraphrase it into something firmer: send what they said. If they are unsure, or if the previous year DID trade and the trial balance was simply taken after closing, do not call this — the other two remedies in get_comparative_source_state are the correct ones. Call get_comparative_source_state first, read out the finding, get their explicit go-ahead, and send the confirm_token it returned. Datavrn refuses if the previous-year figures changed after you read the state, and nothing is recorded. It can be withdrawn in Datavrn if it was recorded in error; withdrawing restores the refusal.

  ConnectorNo auth

• ingest_uploadA

  schedule-iiiA

  Commit a validated upload into the entity’s books. This is a TWO-CALL approval: if the upload has any warnings, or would permanently delete existing trial-balance rows for a period it covers, the first call writes NOTHING and refuses with every warning, the exact record counts, and a short-lived removal_token. Show your user every warning and both counts, get their explicit go-ahead, then resend the SAME call adding removal_token and removal_count exactly as returned. acknowledge_warnings is IGNORED on this connection — the token is the only acknowledgment, so sending it changes nothing. A clean, additive ingest needs no token and succeeds on the first call. Returns the ingestion outcome including any notices.

  Connector

  Destructive

  No auth

• list_grouping_suggestionsA

  schedule-iiiA

  List ungrouped accounts with DETERMINISTIC grouping suggestions (curated rules + name/group-path matching — no AI is involved; Datavrn never applies a suggestion itself). Paginated. Each row carries a reason and a confidence tier: present them to your user GROUPED BY CONFIDENCE, and call out low-confidence and balance-bearing rows for individual attention — a single blanket approval is not a review of the low-confidence tail. Confirm only what your user approves via confirm_groupings. Returns a summary (counts by confidence tier) plus one page of suggestion rows — fetch tier by tier with the confidence filter instead of everything at once; pass include='confirmed' to see already-confirmed groupings.

  ConnectorNo auth

• generate_schedule_iiiA

  schedule-iiiA

  Queue the Schedule III workbook build (returns a job_id to poll with get_job — the build runs as a background job). REFUSES when ungrouped accounts exist unless acknowledged: before acknowledging, present the ungrouped accounts to your user and obtain their explicit go-ahead; record it in acknowledge_reason and pass the exact count in acknowledge_count — an acknowledgement WITHOUT its count is always re-demanded. A multi-month statement period additionally requires acknowledge_multi_month_pnl WITH acknowledge_month_count (confirm with your user that the TBs are period movements, not cumulative). Never acknowledge anything the user has not seen. Once queued, the build usually completes in a few minutes — tell your user their statements are being prepared and poll get_job periodically; do not present the wait as a problem.

  ConnectorNo auth

• get_statement_notesA

  schedule-iiiA

  Read the line-by-line breakdown of a generated statement's notes — every line's current and prior-year amount, and the note total. Pass note_numbers (from get_statement_figures' note_index) to fetch specific notes, or omit for all. Use this to answer "what's in Other Expenses?" or "what makes up trade receivables?". Each line has a kind: 'component' (an additive line), 'subtotal' (a presentational group subtotal — do NOT add it into the total, or you double-count), or 'header'. Fixed-asset / intangible notes carry a `block` per class with gross_block, accumulated depreciation, and net (the additions/deletions movement schedule itself lives in the workbook). If the full set is too large it returns too_large:true with a note_index — fetch note_numbers in small batches. A single very large note (e.g. a PPE schedule or an ageing note) is returned in explicitly-flagged line pages: each page carries the authoritative note total, lines_page, lines_total, and has_more_lines — keep fetching lines_page until has_more_lines is false; never treat one page's lines as the whole note. Amounts are decimal strings in rupees. Figures are Datavrn's deterministic engine output; interpretation is your assistant's.

  ConnectorNo auth

• declare_capture_naA

  schedule-iiiA

  Record that a capture section had NOTHING to report this period, DOES NOT APPLY to this entity, or that this is the entity’s FIRST YEAR (previous-year figures only). These are three different statements and are not interchangeable: "nothing this period" means the section applies but had no activity; "does not apply" means it never applies to this entity at all. This is your user’s professional assertion, recorded as authorised by them — ask which one is true, and never guess. NOT every reason is available for every section — call get_schedule3_workspace and read allowed_reason_codes on the section before you ask your user, so you never put a choice to them that Datavrn will refuse. The restrictions: Settings takes NO answer here at all (it is only answered by saving the settings); share capital and partner capital take only "nothing this period", because those sections are shown only for statement formats they apply to, so "does not apply" can never be true; and "first year" belongs only to previous-year figures. To record a REVIEW being complete (previous-year figures, disclosures) use confirm_capture_review instead; this tool cannot make that assertion. A section can only hold one active answer. If the section’s current answer is still standing, this call refuses — revoke it with revoke_capture_declaration first. If the current answer was already WITHDRAWN by later changes (Datavrn shows the section as unanswered), this call supersedes it: the old answer is marked withdrawn and stays on the record, and the response names what was withdrawn. An answer is never edited in place. Superseding or changing an answer invalidates any finalise approval you already hold — the next finalise_statement will ask you to review the current state again. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.

  Connector

  Destructive

  No auth

• save_partner_capitalA

  schedule-iiiA

  Save the partner or owner capital schedule for an LLP or other non-corporate entity — Note 3a (capital account) or Note 3b (current account), one section per call. Send the COMPLETE schedule for the section you name: anyone you leave out is removed, and a renamed partner reads as one removal plus one addition. If your request would remove anyone, would change the figures of a partner who stays — including their profit-sharing ratio — or would repeat a person’s name that is not already repeated on file, this returns an approval request first and changes NOTHING; tell your user exactly what would change and get their go-ahead before resending with the approval. Two rows with the same person name are both kept: Datavrn never merges them, because two partners may genuinely share a name. A repeated name is therefore saved as a separate row each time it appears, and every one of those rows adds to that person’s balance on the note, so check with your user that there really are that many people before you send a schedule that repeats a name. Adding a partner with a new, different name needs no approval. share_pct is the profit-sharing ratio stated in the LLP or partnership agreement at the reporting date. A ratio that changed part-way through the year cannot be represented here, and a partner who joined or left mid-year cannot be dated — record the position at the reporting date and tell your user the note cannot explain a mid-year change. These figures come from the agreement; Datavrn does not verify them. Datavrn warns about ratios that do not total 100% only when at least TWO capital-account rows carry a ratio, so a partly-filled schedule gets no warning at all — check the total yourself with get_partner_capital. This is your user’s data about named people, recorded as authorised by them. After a successful save, read the section back with get_partner_capital and show your user the new closing balances — this replaces the whole section, and a schedule they cannot see afterwards is a schedule they cannot check. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.

  Connector

  Destructive

  No auth

• save_accounting_policiesA

  schedule-iiiA

  Save the Significant Accounting Policies text (Note 2) your user has chosen, one policy per title. SEND THE COMPLETE SET EVERY TIME: this replaces all of Note 2, so any title you leave out of this call is removed — including one someone answered in the Datavrn app. Call list_statement_policy_choices first and send back every title. If your call would drop a saved policy, Datavrn saves nothing and returns an approval request naming how many would be dropped — show your user, and send the approval back only if they mean to drop them. A complete resend drops nothing and saves straight away. Use the exact policy headings this statement format carries; a heading Datavrn does not recognise is refused and nothing is saved. Resolving a bracketed template choice such as "[FIFO / weighted average]" is an ACCOUNTING POLICY DECISION SPECIFIC TO THIS ENTITY: get your user’s explicit choice, and never pick one because it is the common answer. If a policy was set this year and differs from last year’s answer, that is a CHANGE IN ACCOUNTING POLICY requiring disclosure under AS-5 / Ind AS 8 — tell your user before you save it. Check list_statement_policy_choices first: a row that differs from last year while its captured flag is false is NOT a change — last year’s wording has simply not been carried forward, and unless you send it again this note prints Datavrn’s generic template wording in its place. Saving here re-opens the disclosure review — after your last change, confirm the disclosure review again with confirm_capture_review before generating. Recorded as authorised by the member you name. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.

  Connector

  Destructive

  No auth

• list_replacementsA

  schedule-iiiA

  List what a connected data source’s AUTOMATIC syncs have REPLACED for one entity — each one showing what was overwritten, how many records, and whether it can still be undone. Call this when a user says figures for a past period look wrong or changed on their own, and after any surprise in a period a connector covers. Datavrn keeps the replaced data for 30 days from the moment it was replaced: within that window state is "restorable" and preview_replacement_restore/restore_replacement can put it back; after it, state is "lapsed" — the record of what happened is kept and is still listed here, but it can no longer be undone from this connection, so tell the user to contact Datavrn support if they need that data recovered. "restored" means it has already been put back. Only syncs that ran UNATTENDED are listed: a replacement someone on the team previewed and confirmed themselves is not offered for undo, by design. window_closes_at is the date the undo window shuts. If connection_attributed is false, Datavrn can no longer prove which connection made that replacement — say so rather than naming this one. To find these without a connection id, call get_pending_work: it lists every still-undoable replacement across the entities you can see, with the entity and connection to use here.

  ConnectorNo auth

• list_clientsA

  schedule-iiiA

  List the entities (companies) this credential can work with. Call this first to resolve the client_id every other tool needs. Returns each entity id and name.

  ConnectorNo auth

• create_upload_linkA

  schedule-iiiA

  Mint a single-use, login-free upload link so a file reaches Datavrn WITHOUT passing through your context, where it cannot truncate or corrupt. Use this whenever a human has the file (a trial balance export, etc.) — and also whenever YOU hold the file and it is larger than about 10 KB. This is the RELIABLE path at that size: inlined base64 mutates often enough that the damage arrives as a plausible-looking trial balance rather than an obvious error, while the link delivers the bytes byte-perfect. Two ways to deliver the file: a HUMAN opens upload_url in their browser and chooses the file; a PROGRAMMATIC caller that already holds the file on disk POSTs it to the SEPARATE upload_post_url as a multipart form with a single `file` field (upload_url is the human page and will not accept a POST). The POST reply carries received_file_hash — compare it to your local sha256 before confirming the mapping. The link stages the file for ONE entity and expires in about 15 minutes; nothing is ingested until the column mapping is confirmed.

  ConnectorNo auth

• get_variance_reportA

  schedule-iiiA

  MANAGEMENT data class. Read the existing budget-or-prior variance report for a month; it never recalculates it. Amounts are decimal strings; a null actual or variance means unavailable, never zero. Rows view has whole-report unfiltered rollups and no cross-side grand total; filters affect only rows and filtered grain counts. Explanations view withholds internal notes and may redact structured PII. Filter lines or centres before paging; the signed page_token is source-pinned, so restart at page 1 if source_changed.

  ConnectorNo auth

• copy_capture_declarationsA

  schedule-iiiA

  Copy the previous period’s "nothing this period" and "does not apply" answers into this period, for sections that have no answer yet. It NEVER copies a review confirmation — a review is about this period’s content and cannot be inherited. Last period’s answer is not evidence about this period: list what it would copy to your user, section by section, and get their go-ahead before calling it. Answers already recorded for this period are left alone. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.

  ConnectorNo auth

• preview_replacement_restoreA

  schedule-iiiA

  Show EXACTLY what undoing one automatic sync would do, counted at this moment, and get the approval restore_replacement needs. destroy_count is how many records undoing it would DESTROY — everything currently held for that period, whoever or whatever put it there, including data a colleague uploaded since. restore_count is how many records would be put back. READ BOTH NUMBERS TO YOUR USER IN THEIR OWN TERMS AND GET THEIR EXPLICIT GO-AHEAD BEFORE CALLING restore_replacement. Undoing a sync is itself a destructive act. If blocked_reason comes back non-null, the period is locked by a finalised statement or a sealed run: read that reason out, do not call restore_replacement, and no approval is issued. The approval is single-use, expires in 15 minutes, and is tied to this entity, this sync, this connection, the member you name AND the exact destroy_count returned here. Send that same number back as expected_destroy_count — never a number you adjusted. If the period’s data changes in between, the approval is spent and you start again from here.

  ConnectorNo auth

• confirm_complete_chartA

  schedule-iiiA

  Record your user’s explicit confirmation that one upload is an entity’s COMPLETE CURRENT chart of accounts, so Datavrn starts treating it as evidence when checking whether future files belong to that entity. Recorded as authorised by the member you name. THIS IS A PROFESSIONAL JUDGMENT, NOT A CALCULATION. Datavrn will never make it from the numbers, and neither should you: call preview_chart_rebaseline for that upload first, read its counts to your user, and ask them plainly whether that upload is the entity’s whole book now. Confirming a file that is NOT the entity’s chart teaches Datavrn the wrong chart and weakens wrong-entity detection for that entity from then on. Send back the state_digest and confirm_token from the SAME preview_chart_rebaseline response, unchanged. Datavrn refuses and changes nothing if: the entity’s uploads moved after you were shown those figures, someone already confirmed this upload, the upload no longer needs confirming, or it is one Datavrn asked about directly — for those, answering that question is what settles it. Nothing about the landed figures changes: this affects only which uploads count as evidence of identity.

  ConnectorNo auth

• get_statement_figuresA

  schedule-iiiA

  Read a generated Schedule III statement's figures: the balance-sheet and profit-and-loss faces, current-year and previous-year balance-sheet tie verdicts separately (a null verdict means UNKNOWN, never a pass: either no comparative was captured, or the version predates per-column balance recording), the unclassified count, and the notes listed by number. Also returns bounded exception counts by rule/severity and the frozen control changes versus the immediately previous recorded version; it never recomputes either from live books. Figures come from a generated version (the latest unless you pass a specific version) and match the workbook exactly. If the version was generated before figure reads existed it returns available:false with reason "figures_not_available" and only the legacy flat tie verdict; tell the user to generate the statement again, read the latest version, then retry. For a note's line-by-line breakdown, use its note_index entry with get_statement_notes. Amounts are decimal strings in rupees. ONE EXCEPTION: the profit-and-loss face ends with the statutory earnings-per-share rows, marked kind:"eps". Their figures are ₹ PER SHARE, not rupees of profit — report them as EPS and never add them into a face total. They are null until the weighted average share counts are saved in statement settings. Figures are Datavrn's deterministic engine output; interpretation is your assistant's.

  ConnectorNo auth

• get_pending_workA

  schedule-iiiA

  Answer "what's left to do?" across every entity you can see — one row per entity, with what is blocking its Schedule III statement: whether the trial balance is in, how many accounts are still ungrouped, the latest generated version, and whether it has been finalised. Pass period_label to pick a period, or omit to default to the period most of your entities have a trial balance for (not necessarily the newest — one entity uploading a future period early will not flip the board). Rows include deep links that open the Datavrn web app (a login is needed there). It also answers a second question nothing else here does: restorable_replacements lists automatic connector syncs that REPLACED an entity's data and can still be undone, soonest-closing first, each with the date its 30-day undo window shuts — after that the replaced data cannot be put back, and no message ever announces that clock running out, so raise these with your user rather than waiting to be asked (use list_replacements and preview_replacement_restore on the ids given; restorable_replacements_omitted says how many more were not listed).

  ConnectorNo auth