Skip to main content
Glama
PNPC-MCP-Tally-Prime

PNPC-MCP-Tally-Prime

create_voucher

Create Payment, Receipt, Sales, Purchase, or Journal vouchers in TallyPrime using a simple two-leg debit/credit entry or multi-line entries, with optional bill allocation, cost centres, and manual voucher numbering.

Instructions

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

Input Schema

NameRequiredDescriptionDefault
dateYesVoucher date in DD-MM-YYYY format
modeNoTally's voucher entry mode (the 'Change Voucher Mode' choice in the voucher screen). 'Accounting Invoice' posts it as an invoice with plain ledger lines, the way invoice-mode Tax Invoices are entered — partyLedger is then required. 'As Voucher' posts the normal Dr/Cr voucher view and records that mode. Omit to post the normal voucher view without stamping a mode (right for Payment, Receipt, Contra). For Item Invoice (stock lines) use create_sales_invoice and its siblings instead.
amountNoAmount of the transaction (simple 2-leg mode; omit if using 'entries')
entriesNoFor a voucher with more than 2 lines (e.g. one payment covering three expense ledgers): an array of { ledgerName, amount, type: 'debit'|'credit', billName?, billType?, costCentre?, costCategory?, description? }. Debit and credit amounts must sum to the same total (Tally's double-entry rule) or the call fails with a clear error before reaching Tally. When provided, this replaces debitLedger/creditLedger/amount entirely.
buyerTrnNoThe buyer's TRN as it should appear on THIS voucher, when voucherType is a Sales-side accounting document (e.g. a custom 'Tax Invoice' voucher type entered in Accounting Invoice mode — plain ledger entries, no stock items) — Tally's TRADERCONSVATTINNO/BASICBUYERSSALESTAXNO fields, reverse-engineered from a real such voucher. Only correct when the party ledger IS the buyer (Sales-class); for a Purchase-class voucher the buyer is your own company instead, which this generic field does not distinguish — use create_purchase_invoice's separate buyerTrn/supplierTrn for that case.
buyerNameNoName to print in this voucher's Buyer (Bill to) box, when it should differ from the customer ledger's own name — Tally's per-voucher Party Details mailing name. The ledger itself is not changed. Useful when many sales are posted against one shared ledger (e.g. cash or card sales) but each invoice needs its own readable buyer name.
narrationNoNarration / description for the voucher
referenceNoFree-text reference for this voucher, backed by Tally's voucher-level REFERENCE field (the same field the 'Order no.' UI field on Order-class vouchers uses) — e.g. a supplier's bill/invoice number like 'PI-061538' on a Payment or Journal settling that bill. Independent of voucherNumber and of any per-leg bill reference name (debitBillName/creditBillName/entries[].billName), which is Tally's separate bill-wise settlement mechanism, not this field.
buyerStateNoThe buyer's Emirate/state on this voucher's Party Details (voucher-level STATENAME) — same Sales-class caveat as buyerTrn.
debitLedgerNoLedger name to debit (simple 2-leg mode; omit if using 'entries')
partyLedgerNoThe customer or supplier ledger the invoice is raised on — required with mode 'Accounting Invoice', and must be one of this voucher's own ledger lines (it's placed first and marked as the party, as Tally does).
voucherTypeYesVoucher type, e.g. 'Payment', 'Receipt', 'Sales', 'Purchase', 'Journal'
buyerCountryNoThe buyer's country on this voucher's Party Details (voucher-level COUNTRYOFRESIDENCE) — same Sales-class caveat as buyerTrn.
costCategoryNoCost category the cost centre belongs to. Defaults to 'Primary Cost Category'.
creditLedgerNoLedger name to credit (simple 2-leg mode; omit if using 'entries')
debitBillNameNoBill reference name to allocate the debit leg against, e.g. for a Payment settling a Purchase bill. Omit for vouchers with no bill-wise tracking.
debitBillTypeNo'New Ref' to open a new bill (e.g. a Purchase/Sales invoice), or 'Agst Ref' to settle an existing one by its exact bill reference name (e.g. a Payment/Receipt against a prior invoice). Also accepts 'Advance' or 'On Account'. Defaults to 'New Ref' if debitBillName is set.
referenceDateNoDate for the reference above, in DD-MM-YYYY format (Tally's REFERENCEDATE field). Independent of the voucher's own date. Only meaningful if reference is also set.
voucherNumberNoExplicit voucher number, overriding Tally's automatic numbering. Optional — omit to let Tally assign the next number in its series.
creditBillNameNoSame as debitBillName, for the credit leg.
creditBillTypeNoSame as debitBillType, for the credit leg.
debitCostCentreNoCost centre to allocate the debit leg to (optional).
creditCostCentreNoCost centre to allocate the credit leg to (optional).
debitDescriptionNoAdditional description lines for the debit leg — Tally's built-in 'Provide Additional Descriptions for Ledgers' text shown in italics under that ledger line (one array entry per line, e.g. ['For KK Trading and', 'Manis Trading']). Optional.
creditDescriptionNoSame as debitDescription, for the credit leg.
placeOfSupplyCountryNoUAE VAT Place of Supply Country (Tally's PLACEOFSUPPLYCOUNTRY field), e.g. 'UAE'.
placeOfSupplyEmirateNoUAE VAT Place of Supply Emirate for this voucher (Tally's EMIRATEPOS field) — for a standard domestic supply this is normally your own company's Emirate (check get_company_info).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.1
    • addedInput schema / properties / buyerName
      Added value: +{
      +  "description": "Name to print in this voucher's Buyer (Bill to) box, when it should differ from the customer ledger's own name — Tally's per-voucher Party Details mailing name. The ledger itself is not changed. Useful when many sales are posted against one shared ledger (e.g. cash or card sales) but each invoice needs its own readable buyer name.",
      +  "type": "string"
      +}
  2. Changed2 schema fields changedv1.14.0
    • addedInput schema / properties / mode
      Added value: +{
      +  "description": "Tally's voucher entry mode (the 'Change Voucher Mode' choice in the voucher screen). 'Accounting Invoice' posts it as an invoice with plain ledger lines, the way invoice-mode Tax Invoices are entered — partyLedger is then required. 'As Voucher' posts the normal Dr/Cr voucher view and records that mode. Omit to post the normal voucher view without stamping a mode (right for Payment, Receipt, Contra). For Item Invoice (stock lines) use create_sales_invoice and its siblings instead.",
      +  "enum": [
      +    "As Voucher",
      +    "Accounting Invoice"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / partyLedger
      Added value: +{
      +  "description": "The customer or supplier ledger the invoice is raised on — required with mode 'Accounting Invoice', and must be one of this voucher's own ledger lines (it's placed first and marked as the party, as Tally does).",
      +  "type": "string"
      +}
  3. Changed4 schema fields changedv1.13.1
    • addedInput schema / properties / creditDescription
      Added value: +{
      +  "description": "Same as debitDescription, for the credit leg.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / debitDescription
      Added value: +{
      +  "description": "Additional description lines for the debit leg — Tally's built-in 'Provide Additional Descriptions for Ledgers' text shown in italics under that ledger line (one array entry per line, e.g. ['For KK Trading and', 'Manis Trading']). Optional.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / entries / description
      Previous value: -"For a voucher with more than 2 lines (e.g. one payment covering three expense ledgers): an array of { ledgerName, amount, type: 'debit'|'credit', billName?, billType?, costCentre?, costCategory? }. Debit and credit amounts must sum to the same total (Tally's double-entry rule) or the call fails with a clear error before reaching Tally. When provided, this replaces debitLedger/creditLedger/amount entirely."New value: +"For a voucher with more than 2 lines (e.g. one payment covering three expense ledgers): an array of { ledgerName, amount, type: 'debit'|'credit', billName?, billType?, costCentre?, costCategory?, description? }. Debit and credit amounts must sum to the same total (Tally's double-entry rule) or the call fails with a clear error before reaching Tally. When provided, this replaces debitLedger/creditLedger/amount entirely."
    • addedInput schema / properties / entries / items / properties / description
      Added value: +{
      +  "description": "Additional description lines for this ledger line, one array entry per line.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  4. Changed8 schema fields changedv1.11.2
    • addedInput schema / properties / buyerCountry
      Added value: +{
      +  "description": "The buyer's country on this voucher's Party Details (voucher-level COUNTRYOFRESIDENCE) — same Sales-class caveat as buyerTrn.",
      +  "type": "string"
      +}
    • addedInput schema / properties / buyerState
      Added value: +{
      +  "description": "The buyer's Emirate/state on this voucher's Party Details (voucher-level STATENAME) — same Sales-class caveat as buyerTrn.",
      +  "type": "string"
      +}
    • addedInput schema / properties / buyerTrn
      Added value: +{
      +  "description": "The buyer's TRN as it should appear on THIS voucher, when voucherType is a Sales-side accounting document (e.g. a custom 'Tax Invoice' voucher type entered in Accounting Invoice mode — plain ledger entries, no stock items) — Tally's TRADERCONSVATTINNO/BASICBUYERSSALESTAXNO fields, reverse-engineered from a real such voucher. Only correct when the party ledger IS the buyer (Sales-class); for a Purchase-class voucher the buyer is your own company instead, which this generic field does not distinguish — use create_purchase_invoice's separate buyerTrn/supplierTrn for that case.",
      +  "type": "string"
      +}
    • addedInput schema / properties / placeOfSupplyCountry
      Added value: +{
      +  "description": "UAE VAT Place of Supply Country (Tally's PLACEOFSUPPLYCOUNTRY field), e.g. 'UAE'.",
      +  "type": "string"
      +}
    • addedInput schema / properties / placeOfSupplyEmirate
      Added value: +{
      +  "description": "UAE VAT Place of Supply Emirate for this voucher (Tally's EMIRATEPOS field) — for a standard domestic supply this is normally your own company's Emirate (check get_company_info).",
      +  "type": "string"
      +}
    • addedInput schema / properties / reference
      Added value: +{
      +  "description": "Free-text reference for this voucher, backed by Tally's voucher-level REFERENCE field (the same field the 'Order no.' UI field on Order-class vouchers uses) — e.g. a supplier's bill/invoice number like 'PI-061538' on a Payment or Journal settling that bill. Independent of voucherNumber and of any per-leg bill reference name (debitBillName/creditBillName/entries[].billName), which is Tally's separate bill-wise settlement mechanism, not this field.",
      +  "type": "string"
      +}
    • addedInput schema / properties / referenceDate
      Added value: +{
      +  "description": "Date for the reference above, in DD-MM-YYYY format (Tally's REFERENCEDATE field). Independent of the voucher's own date. Only meaningful if reference is also set.",
      +  "type": "string"
      +}
    • addedInput schema / properties / voucherNumber
      Added value: +{
      +  "description": "Explicit voucher number, overriding Tally's automatic numbering. Optional — omit to let Tally assign the next number in its series.",
      +  "type": "string"
      +}
  5. Changed5 schema fields changedv1.0.4
    • changedInput schema / properties / amount / description
      Previous value: -"Amount of the transaction"New value: +"Amount of the transaction (simple 2-leg mode; omit if using 'entries')"
    • changedInput schema / properties / creditLedger / description
      Previous value: -"Ledger name to credit"New value: +"Ledger name to credit (simple 2-leg mode; omit if using 'entries')"
    • changedInput schema / properties / debitLedger / description
      Previous value: -"Ledger name to debit"New value: +"Ledger name to debit (simple 2-leg mode; omit if using 'entries')"
    • addedInput schema / properties / entries
      Added value: +{
      +  "description": "For a voucher with more than 2 lines (e.g. one payment covering three expense ledgers): an array of { ledgerName, amount, type: 'debit'|'credit', billName?, billType?, costCentre?, costCategory? }. Debit and credit amounts must sum to the same total (Tally's double-entry rule) or the call fails with a clear error before reaching Tally. When provided, this replaces debitLedger/creditLedger/amount entirely.",
      +  "items": {
      +    "properties": {
      +      "amount": {
      +        "type": "number"
      +      },
      +      "billName": {
      +        "type": "string"
      +      },
      +      "billType": {
      +        "type": "string"
      +      },
      +      "costCategory": {
      +        "type": "string"
      +      },
      +      "costCentre": {
      +        "type": "string"
      +      },
      +      "ledgerName": {
      +        "type": "string"
      +      },
      +      "type": {
      +        "enum": [
      +          "debit",
      +          "credit"
      +        ],
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "ledgerName",
      +      "amount",
      +      "type"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "voucherType",
      -  "date",
      -  "debitLedger",
      -  "creditLedger",
      -  "amount"
      -]New value: +[
      +  "voucherType",
      +  "date"
      +]
  6. First observedv1.0.3

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare it is a non-read-only, non-idempotent, non-destructive, closed-world write. Beyond that, the description discloses that unbalanced entries fail with a clear error before reaching Tally and documents a real live auto-numbering bug, which is genuinely useful behavioral context. It does not mention the preview_write/confirm_write flow that sibling tools imply, nor set_company prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with purpose and then the two input modes, with the riskiest parameter guidance last. The parenthetical anecdote about the 'PNPC/2026/...' series is longer than needed but does justify the otherwise surprising instruction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 27-parameter creation tool with full schema coverage and no output schema, the description covers the decision-critical parts: which input shape to use, the auto-numbering pitfall, and where to look up the next number. Nothing an agent needs in order to call it correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains all 27 parameters. The description adds real meaning for voucherNumber (override semantics plus the concrete numbering-series failure) and for the entries-vs-simple mutual exclusivity, but adds nothing about date format or party handling. Baseline 3 with a small lift.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a new voucher ... in TallyPrime') and immediately enumerates the supported voucher types. It also distinguishes the two input shapes (2-leg vs 'entries'), so an agent understands what the tool produces without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use the simple debitLedger/creditLedger/amount form versus the 'entries' array, and when to omit versus set voucherNumber, including a directive to check get_vouchers first. It does not mention update_voucher or create_vouchers_batch as alternatives for editing or bulk posting, which is the remaining gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools