OptiVida
Open OptiVida

Posting to Tally

What the connector checks first, how duplicates are avoided, and reading the per-line result.

Posting sends the approved lines to the company open in Tally, one voucher each, and reports what happened to every one.

Before you post

Only lines with the status Approved are sent. Suggested and undecided lines stay where they are.

LedgerReview linesPost to Tally

The button sits in the bar along the bottom of the page and carries the number of approved lines. On a wider screen the bar also shows where the connector stands: Connected and the computer's name when it is ready to post.

What the connector checks first

Before a voucher is sent, the connector reads the company's masters again and checks that:

  • both ledgers exist in the company, by exact name;
  • the voucher type exists;
  • the two legs balance to the paise;
  • the date is a real date and not before the day the company's books begin.

A line that fails is marked Failed with the reason, and is not sent. These checks exist because Tally reports some failures with no message at all.

Duplicates

Tally does not refuse a voucher it has already been given; sending the same batch twice would create every voucher twice. So the connector first reads the vouchers already in the company for the statement's dates, and any line whose date, narration and amount are already there is marked Already in Tally and skipped.

That makes a retry safe: after a connector or network failure part-way through, post again and only the missing lines are sent. The narration is compared with its spaces removed, so the same statement uploaded twice is recognised even if the two extractions spaced the text differently.

Reading the result

Posted
Created in Tally. The voucher id Tally assigned is shown beside the status.
Already in Tally
Skipped by the duplicate check.
Failed
Refused by the checks above, or by Tally. The reason is on the line, and the ledger picker stays open on it: choose a different ledger (or use the retry control to keep the same one) and the line is approved again with the error cleared, ready for the next post. The undo control sends it back to review instead.

The statement's own status becomes Posted once every line is either posted or already in Tally.

If you cannot see them in Tally

Day Book shows only the period currently selected in Tally. Posting does not depend on that period, but seeing the result does: press Alt+F2 and set the period to the statement's months, or Alt+G and search the voucher's narration.

Two refusals that are Tally's state, not the statement

Voucher date is missing
The date was sent and is valid; Tally is refusing that date in that company. Enter one voucher on the same date by hand in Tally to see the reason it gives, fix it there, then use the retry control on the failed lines.
Refused without a reason
Tally reports one exception and no text over the gateway, but it does record the reason: in Tally press Alt+O, choose Import, then Exceptions, and read the line for the voucher. The one met so far was "Voucher No. is missing", from a voucher type that numbers manually or with manual override; the connector now reads the type's numbering and assigns the next number itself. Also check that the period the company is open in (Alt+F2) covers the statement's dates, then retry.

Lines that were already created are skipped by the duplicate check on the retry, so it is always safe to post again after fixing Tally.

Warning

Vouchers land in the company as ordinary Payment, Receipt and Contra entries under the next voucher numbers. To reverse one, delete it in Tally; OptiVida does not delete or alter what it has posted.

Last updated 25 Sept 2026

Still stuck? Ask us