The 16/10 alpha test showed that cash rows often start with no suggestion, or with a weak one. This page shows the cause, four ways for the app to handle cash rows, and a mock of the Suggestions and Review steps where you can try each way with the keyboard. All sample rows are made up from the patterns in the alpha data. They contain no person names and no real account or card numbers.
SELF-CHQPAID- SARDARCHOWK, got no suggestion from the server. Only the Miracle history clue helped 4 of them.CASHDEPOSITBY-SELF-… is one glued word, so it got no suggestion either. The cause is the same as for SELF cheques.The cash rule (server/ledger_signals.go, the first categories entry) reads the narration as separate letter runs. For a SELF cheque it needs SELF plus the separate word CHQ or PAID. In SELF-CHQPAID- the word is CHQPAID, so the rule does not see it. For deposits it needs CASH plus DEPOSIT or BY. In CASHDEPOSITBY they are one word.
The 69% is not a measure of cash rows. The confidence table pools every category (cash, loans, bills, rent, salary…) into one situation, “category one alone” (267 right of 388). Cash rows are much more accurate than that pool, as the book check below shows.
These are labelled statement rows only (an unambiguous match to one bank-ledger posting). I ran the current rule and the proposed rule over the narrations and compared them with the ledger in the books. “Right” means the books post the row to the Cash-in-hand ledger. Every company has exactly one Cash-in-hand ledger. Its many GST “Cash Ledger(CGST)…” ledgers are in another group, and the rule already leaves them out.
| Row kind (rule part) | Example | Rows | Booked to cash | Today |
|---|---|---|---|---|
| CASH + a separate word (WDL, PAID TO SELF, DEP, BY…) | CASH CHEQUE/PAID TO SELF | 95 | 95 (100%) | found, 69% red |
| SELF + glued CHQPAID (missed today) | SELF-CHQPAID- JETPUR | 10 | 10 (100%) | no suggestion |
| Glued CASHDEPOSITBY (missed today) | CASHDEPOSITBY-SELF-… | 5 | 5 (100%) | no suggestion |
| ATW | ATW-XXXXXX4821-S1ACJT07-JETPUR | 13 | 13 (100%) | found, 69% red |
| NWD | NWD-XXXXXX4821-… | 9 | 8 (89%) | found, 69% red |
| ATM (without POS) | ATM WDL/S1CNR745/… | 8 | 6 (75%) | found, 69% red |
| POS + ATM (a debit-card purchase) | POS ATM PUR HP COCO … | 6 | 0 (0%) | wrongly suggests Cash |
All 3 withdrawals that were not booked to cash (1 NWD, 2 ATM) went to Suspense in the books. None went to another party. With POS rows left out, cash withdrawals are 126 of 129 right (97.7%). That is the same accuracy as today’s exact (auto-saved) rules (97.6% in the 12/10 audit). Cash deposits are 11 of 11, but that is a small sample. Also, a deposit is often a customer’s payment (“CASH DEP BY <party>”).
Pick an option and a company setup, then click a row in the mock (or Tab into it) and use the keys. The steps are fixed when the review starts, as in the app. “Start again” runs the start again.
| 1 · Green suggestion | 2 · Auto-save withdrawals Recommended | 3 · Cash group | 4 · Ask once | |
|---|---|---|---|---|
| Work for 17 cash rows | Ctrl+Shift+Enter (all suggestions), or Enter twice on each row | None. Check them in Review if you want. | One Enter on the group | One Enter per import, or none after “every import” |
| Wrong cash booking | Lowest: you confirm each row, or all at once | About 2 in 100 withdrawals (the books use Suspense). Saved without asking, but listed under Cash Account in Review and easy to change | Low: one key books the group, but its rows are shown right below | Low per import. “Every import” then works like 2, with no reminder |
| Unsaved rows lost at export (alpha: 21 of 50) | Still possible. Green rows sort last, below the rows that need thought | Not for withdrawals | Less likely: the group is first | Not after Yes |
| Fits current app rules | Yes, no UI change | Yes. Exact matches already exist (UPI, account no., same narration) and show “Matched · …” in Review | New: a group header inside the shared table, which interacts with sorting, row selection and Alt+G | New: a modal before the steps are fixed, plus a per-party setting on the server |
| Several / no cash ledgers | Two: both suggested, yellow. None: Suspense + note | Two: falls back to 1 (yellow). None: Suspense + note | Two: Enter on the group asks which. None: no group | Two: choose in the dialog. None: choose any ledger, or leave in Suspense |
| Cash deposits | Green suggestion (BY SELF); party first when named | Never auto-saved: green suggestion | Inside the group, counted separately | Not in the question: they stay suggestions |
| Older installed apps | Same benefit | Same benefit (server decides; Review already shows “Matched · Looks like cash”) | Need the update | Need the update |
| Effort | S: rule fixes + confidence by category + regenerate the table | M: S + exact level for cash withdrawals only + tests | M–L: S + table grouping + keys + tests | M: S + dialog + per-party setting + tracking + tests |
Cash withdrawals are the most common rows that need no thought, and the books show they are as safe as today’s exact rules. The alpha shows that a suggestion left unsaved is lost. If the app saves withdrawals itself, the user's attention goes to the rows that need it. Cash deposits, plain “ATM” rows and companies with two cash ledgers keep a real choice, so they stay suggestions with an honest green or yellow mark. Nothing is booked silently where the books show a real choice.
CHQPAID, CHQWDL). Keep the exclusion for NEFT, RTGS, IMPS, UPI, TRF and TRANSFER. (+10 of 10 in the books, +14 alpha rows)CASHDEPOSITBY, CASHWDL). The charge check still runs first, so CASHWITHDRAWCHR stays a bank charge. (+5 of 5)category cash one alone instead of the pooled category one alone), then regenerate ledger_confidence_table.go with MATCHEVAL_CONFIDENCE=write. Cash should then measure about 95–98% (green). Loans, bills and the others get their own, more honest marks. This is a change for every category, so the replay must show that the ordering does not get worse.Seen but out of scope: the charge IBCASHWDLCHGSINCL GST (₹59) is not found as a bank charge, because CHGS is inside the glued word, not at its end.