Finance Controller

The judgement layer for a close. You supply both sides of a reconciliation and the rule that decides a match; it lines them up and reports what matched, what only nearly did, and what matched nothing on either side — with the difference always stated, because that is the number a controller signs off. IT CARRIES NO MATCH CONFIDENCE, AND THAT IS THE PRODUCT. The tool this consolidates scored every candidate pair — 0.95 for an exact amount on the same date, 0.85 within three days, 0.65 within ten, 0.6 for an amount within one per cent — then used a floor of 0.5 and a threshold of 0.9 to sort them into AUTO-RECONCILED, REVIEW and UNMATCHED. Nothing measured chose any of those eight numbers, and the output decides which entries a human never looks at again. SO THE RULE IS YOURS: the amount tolerance, the date window, and whether a shared reference is required. A pair satisfying it is matched. Everything else sharing an amount or a reference is reported as a candidate WITH the exact amount difference and the exact number of days between the two — evidence a person settles, not a number that settles it for them. THE TOLERANCE DEFAULTS TO ZERO, not to a cent. A tolerance is a decision about your currency and your data, and a default of 0.01 quietly reconciles a break somebody may care about. A MATCH IS AN ARITHMETIC COINCIDENCE that satisfies your rule, not a statement that two entries are the same transaction. Two invoices for the same amount on the same day match each other as readily as either matches the right one — which is why the reference requirement exists, why every candidate is reported rather than resolved, and why the one-to-one assignment order is stated rather than hidden. Provided-data: it reaches no ledger, posts nothing and changes nothing. It reads what you paste.