How Tally investigates unknown money

What It Tries, In Order

A deposit nobody recognizes is the transaction most likely to sit untouched for months. Tally works those ordinary rows deliberately: it identifies what it can prove, posts a best-fit account when research is enough, and leaves unresolved ordinary profit-and-loss rows uncoded in Ready for accountant review.

Firm memory and prior answers. If this merchant was identified before — for this company or elsewhere in your firm — Tally reuses that answer rather than starting from zero.

Merchant research. Tally builds a dossier from the descriptor, the history, and the company's chart of accounts, then judges each ordinary row on its own.

Recognizable bank activity. A bank charge is coded straight to the company's Bank Fees or Bank Charges account when that account exists and is active.

Probable transfers. A row that looks like money moving between the company's own accounts is handed to pair settlement instead of being categorized. See How Tally settles transfers and card payments.

What Happens When Research Cannot Name An Ordinary Account

When ordinary research cannot prove a specific revenue or expense treatment, Tally does not invent a miscellaneous category. It leaves the row uncoded in Ready with its suggestion and rationale. An accountant can code the row or use Ask to post an eligible row to one of these accounts:

• the company's bound Management Review - Income account for deposits;
• the company's bound Management Review - Expense account for withdrawals.

Using Ask Client moves the row into the Ask Client workflow. The guided Fast Coding workflow sends the grouped request when a designated recipient is available. The underlying review account is posted bookkeeping awaiting better context. It appears in Fast Coding and as the final section of the Profit & Loss. It never blocks reports, reconciliation, or unrelated work, and posting there never creates a bank rule.

Special accounting, transfers, card payments, checks still in quarantine, warnings, pending rows, reconciled rows, and locked periods stay in their exact workflows. They do not fall into Ask Client through ordinary residue.

Older ordinary client questions created before the Ask Client cutover may resolve so coding can continue. New manual requests you create still fence their linked rows until you finish them.

Reading The Report

A clean run says so plainly: every ordinary dollar is either best-fit posted or left in Ready for accountant review.

Your Part

Code lower-confidence rows from Ready, or use Ask to move eligible rows to Ask Client. Recode Ask Client rows when better context arrives. They are already on the books, so later context updates the category instead of hunting uncoded residue.

Do not clear an unknown deposit into a catch-all income account just to empty a queue. Ask Client exists so ordinary uncertainty stays visible without misstating a more specific revenue account.

If a deposit is large, repeated, or looks like it may not belong to this company at all, leave it in Ready or its special workflow and create a support ticket with the company, account, date, amount, and description.

Related

• How Tally codes your bank feed — the broader coding run this fits inside.
• Ask a company owner for an answer or file — how firm-created questions reach the owner and come back.