Alpha fixes: 5 decisions before the final PR

1Cheque rows the books booked two ways

When the books booked the same cheque text to two different ledgers, what should the automatic fill do?

With #149, one choice for a cheque fills the payee's other cheques with the same text. That is the whole point: in the alpha, KESARI NANDAN ART had 10 "SELF-CHQPAID" cheques, and after 2 choices the other 8 still waited. On the production copy, #149 would fill 66 waiting rows (62 SELF cheques to Cash, 4 JAY ART cheques to JAY ART), all right.

But sometimes the accountant booked the same cheque text to two ledgers. Then the fill copies the earlier booking, and it is wrong. The replay found 2 such rows (names replaced):

Here the narration itself names the right ledger, and the name matcher finds it. The reviewer tested a small fix: on a cheque row, when a name in the text points to another ledger more strongly than the learned one, do not save automatically; suggest instead. Result: wrong saves 3 → 2, and no good row is lost. I will apply this fix in every option below.

Nothing in the text tells these two apart. The person collected cash once for wages and once as cash. No rule can fix this row without stopping the fill after one choice.

Why A: the replay shows 96–120 right saves gained for 1 wrong one, and the wrong one comes from inconsistent books, not from a bad rule. Every automatic save is still visible in Review.

2Cheques that print no payee name

When a cheque row prints only a town or a bank (no payee), should one choice still fill the others?

#149 keeps a cheque's number (so no fill) when the text has no payee word. It decides this with word lists: cheque words (CHQ, CLG, MICR…), bank codes, and a list of clearing towns (MUMB, JETPUR…). Any other word counts as a payee. So a town or bank that is not on a list is taken as the payee, and different customers' cheques can look like one payee. Both the code review tool (OpenQodex) and the reviewer flagged this.

The SBI row is real: a ₹1,05,655 deposit on 13/10/2023 in one company's HDFC statement. The books do not hold it, so the replay cannot say who it was from. The BHAKTINAGAR rows are cheques that print only the branch; the books put all of them to Cash.

How often today: in the replay data and the production copy, this caused no wrong save. Real cheque rows without a payee are already handled: "CAS PRES CHQ" (3 different suppliers in ASMARK's books) keeps its number. "CHQ PAID- CHQPAID- BHAKTINAGAR-" (4 rows, all Cash in the books) fills, which is right there. Rows like the SBI example exist in the data but were never booked differently.

Why A: it removes the case we can name (bank names) at low cost, keeps the behaviour you chose, and no wrong save of this kind has appeared in real data.

3How sure a tie looks

When two or three ledgers still tie, what colour should the mark be?

A tie is when the matcher finds two or three ledgers equally likely, for example:

In the option you chose, #153 divides the confidence by the number of tied ledgers. A 91% match tied two ways shows as 45%, so every tie is red. But the replay measured how often the first tied ledger is right: two-way ties 31 of 44 (70%), three-way ties 8 of 13 (62%), because #153 now orders tied ledgers by direction and group first.

There is a side effect. The Miracle history clue replaces the server's suggestion when the server's number is lower. A "same amount in the books" clue (50%, right about half the time) now beats every tie, and a "recurring" clue (78%) always does. So a sensible tied suggestion can be replaced by a weaker guess.

Why A: the mark is meant to say how likely the suggestion is (90/70 rule). The measured number does that; dividing does not.

4No pop-up: fill a payee's other entries automatically

You asked: if the pop-up lists a payee's other entries, all ticked, how often would the user keep them all? If nearly always, drop the pop-up and fill them automatically. Here is the measurement, and the one choice left.

After you choose a ledger for one entry, a pop-up (on main since 16/10, #115) lists the payee's other open entries, all ticked; Enter saves them all. #152 adds a "Now suggested" part on the Suspense step. Both would go. The payee groups are the app's own: same UPI ID, same account number, or same narration pattern. The pop-up does not look at the direction, so a payee's receipts and payments are offered together.

For every payee group in every statement, I took the books' ledger for the group's first open entry as "your choice", and checked the books' ledger of each entry the pop-up would offer. "All offered entries right" means every offered entry is booked to that same ledger, so pressing Enter with everything ticked (or filling automatically) would be right.

• The other direction is where it goes wrong. 5 of the 7 wrong cases are a party that both buys and sells: payments booked to GOODS PURCHASE but receipts to GOODS SALES; payments to LABOUR WAGES EXPENSE but receipts to JOBWORK INCOME.
• The 2 left in the same direction are Row A and Row B from decision 1 (the books booked the same text two ways). The Row A fix covers one of them here too.
• The pop-up would also offer 24 entries the books never booked; they are not counted above.

• In all 6 repeat-payee groups where a user chose a ledger, every entry of that payee got the same ledger. No user ever split a payee.
• In 3 of those groups the rest were left unsaved and went to Suspense: 8 + 2 SELF cheques (Cash) and 1 JAY ART cheque. Filling automatically would have saved these 11 entries.
• Production cannot show how users treat the pop-up itself: its tracking event (entry.offer) arrives with #152, and the 16/10 app grouped no cheques (the cheque number split them until #149).

In the same direction, users would keep everything ticked 98–99% of the time. The pop-up asks a question whose answer is almost always yes, so your call to drop it fits the data. The proposal: no pop-up anywhere in the normal flow; a choice fills the payee's other open entries in the same direction automatically; the status line says "8 more entries got Cash Account"; every filled entry shows in Review and can be changed there; the Settings switch for the pop-up goes. The "N entries here now have a suggestion" line (#152) and the Export list (#150) stay as the last checks for anything not filled.

Why A: it removes the pop-up as you want, and "same direction" is the one rule that keeps the fill nearly always right.

5How the five PRs reach main

Who makes the fixes, and how do the five PRs become one change on main?

Today the five PRs point at matching/alpha-fixes, which is 3 commits behind main. Combining them needs conflict fixes in 7 files and one shared generated file (the confidence table) made once on the combined code. Besides your decisions, these fixes need no choice (owner in brackets):

• Accept-all also saves contra entries on the Suspense step (#152): leave entries with an undecided contra out, and count only shown rows.
• Down on the Export step jumps up into the new list from Save or a checkbox (#150): limit it to the list's own heading.
• Cash line touches the page header on the latest main (#148): add main's data-above-table mark.
• SELF cheques through clearing ("CHQ PAID-MICR CTS-…-SELF", "TO CLG SELF CHQ") are saved as cash (#148), but they are usually transfers to the owner's other bank: suggest them, do not save them.
• Small items: wording ("1 cash withdrawal was saved … by itself"), docs that say "waits a second", help-dialog text, a duplicate import, a tab-storage key that is never cleaned.

Why A: parallel fixes by the owners, one combined check before main, and one clean commit on main.

6One correction on a SELF cheque changes all of them

You change one SELF cheque from Cash to another ledger. Should the other SELF cheques follow?

With #148, SELF cheques ("SELF-CHQPAID- SARDARCHOWK") are saved to Cash Account automatically. With #149, cheques with the same text share one payee pattern (the cheque number no longer splits them). Together, these interact:

What the books say: in the 10 companies' books, all 99 SELF cheques were booked to Cash Account (5 more were never booked). In the alpha, every SELF cheque a user touched also went to Cash. A SELF cheque that is not cash is a one-off exception, so spreading that exception is almost always wrong.

The independent reviewer reproduced this with a test. It is the same kind of case as Row B in decision 1, but here it spreads to every SELF cheque, not one row.

Why A: the books never book SELF cheques anywhere but Cash, so one exception should stay an exception.

7Should the fill change entries you chose yourself?

When you change a ledger, the app fills the same payee's entries that still had the old ledger. Should that include entries you set by hand?

Decision 4 made the payee fill automatic, with no pop-up. The fill takes the payee's open entries in the same direction: no choice, Suspense, or still the old ledger of the entry you changed. That last part came from the old pop-up, which asked first. Now nothing asks, so this happens:

Both reviewers flagged this. The 99.2% accuracy in decision 4 was measured on open entries, not on replacing your own choices. On the other hand, an entry filled automatically a moment ago (by matching or by the fill) has no choice of yours to protect.

Why A: automatic fill saves key presses on what you have not decided yet; it should never overrule what you have.