Tally Bank Reconciliation for Split and Net Settlements

Bank reconciliation gets harder when one receipt covers several invoices or one invoice is settled through several receipts. An amount-only matching rule may look convincing while connecting the wrong transactions. Tally automation should help the reviewer understand those relationships, not hide them.

TallyPrime's bank reconciliation documentation describes its reconciliation facilities. Supported bank formats and features depend on your environment. The workflow below focuses on the surrounding controls for split, combined, and net settlements rather than prescribing accounting treatment.

Start with the settlement story

Ask how money actually arrives. A customer may pay several invoices together. A payment provider may deduct fees before settlement. A receipt may include an advance or a partial payment. These patterns need different matching evidence.

For each source, identify the useful references: bank transaction reference, settlement ID, customer remittance advice, invoice allocation, and date. Preserve the bank statement as received and store any cleaned comparison data separately.

Do not assume the bank transaction date equals the invoice date or the date the business recorded the receipt. Record each date with its meaning. A date window used for candidate matching should be approved by finance and should not turn every nearby amount into a match.

Separate candidates from confirmed matches

Create candidate groups based on reliable references before considering arithmetic alone. The sum of several open invoices may equal a bank receipt by coincidence, especially in a high-volume business with repeated price points.

A potential match should show why it was proposed. The reviewer needs to see references, components, dates, and unresolved differences. A high confidence label without that explanation is difficult to trust when the amounts matter.

An illustrative combined receipt

Suppose a customer sends INR 30,000 covering invoices of INR 12,000 and INR 18,000. Another pair of open invoices also totals INR 30,000. An amount-only algorithm cannot distinguish the intended allocation.

The useful evidence is the customer's remittance reference or another approved allocation record. The workflow presents the candidates, asks for that evidence if it is missing, and records the confirmed grouping. It does not choose the oldest pair merely because that makes the unmatched total smaller.

Now suppose the receipt is INR 29,700. The INR 300 difference might have several explanations. Do not automatically call it a fee, discount, or write-off. Finance must decide the treatment and supporting entry under the business's accounting policy.

Keep net settlements explainable

For provider settlements, reconcile the settlement report to the bank entry and then reconcile the report's components to sales, refunds, and other relevant records. This is a different comparison from matching individual customer invoices directly to the bank.

Preserve the settlement ID across the workflow. Record gross activity, deductions, adjustments, and net cash as separate values where the source provides them. If the numbers do not bridge, create an exception rather than forcing a balancing amount into a generic ledger.

Tax treatment of fees and adjustments is outside the scope of a matching engine. Have your finance team or CA define how those components should be recorded. Automation can apply an approved mapping consistently, but it should not invent the policy.

Protect against repeated statements

The same bank period may be downloaded and imported more than once. Track the source account, statement range, source file fingerprint, and transaction references. File-level detection is helpful, but transaction-level checks are also needed when overlapping periods are exported.

If the bank format changes, stop the parser or flag the changed fields before creating misleading matches. A column shift can make narration look like a reference or turn a debit into a credit. Include format validation in the import process.

Tally's bank statement import guide is the reference for supported product behaviour. Check your bank and format before promising a fully automatic import route. Keep manual review available for unsupported or ambiguous records.

Make reversals and edits visible

A match is not necessarily permanent. A returned payment, corrected voucher, or amended allocation can change the reconciliation. Record which source versions and destination records supported the original match.

When an input changes, flag the affected relationship for review. Do not silently mark it as unmatched without preserving the earlier decision, and do not keep a green matched status against values that no longer agree.

Restrict who can approve adjustments and overrides. The person resolving an import-format problem should not automatically have permission to write off a balance. Separate technical recovery from accounting authority.

Pilot with deliberately awkward records

Use a test set containing exact matches, combined receipts, partial payments, duplicate statements, net settlements, and a reversal. Reconcile the resulting balances as well as individual matches. Ask the reviewer to explain every adjustment from the saved evidence.

Measure unresolved value, age of exceptions, and time spent gathering remittance evidence. A high matching percentage can still hide the few cases that cause most of the month-end work. Improving references at the source may deliver a better result than loosening the matching rules.

Read the GST and Tally automation guide, explore finance automation services, and describe your settlement pattern. A redacted bank row and matching settlement example are more useful for scoping than a promise to "automate reconciliation" without seeing the data.