Inspiration
Small shop owners get paid in three ways at once: cash, UPI and credit. They record sales in a notebook or a basic billing app. Nothing checks the two against each other, so a UPI payment with no bill, or a credit due that nobody follows up, can go unnoticed until the month-end check, if it is noticed at all. Official records of small businesses are often thin, which can make formal credit harder to get.
What it does
UNIFY reads a shop's sales records and payment records, matches them automatically, and sends the owner one short plain-language alert at the end of the day, in Tamil or English. It flags three kinds of possible mismatch: Payment with no bill: money came in, but no sale was recorded. Bill with no payment: goods went out on credit and the payment never showed up. Possible duplicate: the same amount was logged twice within minutes. Honest limits: UNIFY only flags possible mismatches for the owner to check. It gives no tax or legal advice, and it cannot see cash that was never recorded anywhere.
It is built for the owner, not the accountant: one daily message instead of a dashboard, and no need to switch billing apps.
How we built it
Language: Python (standard library only, with datetime). Prototype: unify_match.py, a rule-based matching engine run on 30 synthetic records (20 bills + 10 payments) that we wrote ourselves, covering cash, UPI, marketplace and credit entries. Rules: Duplicate check first: same amount and mode within 5 minutes. Credit bills match only a payment from the same customer, for the same amount, made after the bill. UPI and marketplace bills match the closest unused payment of the same amount within 60 minutes. Each payment is used only once. Leftover payments become "payment with no bill". Cash bills are counted but cannot be verified. Alerts: plain sentence templates with the numbers filled in, written once in Tamil and English. No AI or translation service is needed for the alert text. We built it with AI assistance and then read, tested and modified the code ourselves so we can explain every rule.
Challenges we ran into
Choosing one user. "Small businesses" is too broad, so we anchored the story on one neighbourhood owner. Home sellers and local traders are the next users, not the starting point.
Not overclaiming. Our first pitch said "every rupee is verified". That is impossible for unrecorded cash, so we reworded it to "possible mismatches" and print the cash limit in the output itself.
Honest evidence. Our test data is synthetic, so we report "3 of 3 planted mismatches flagged on sample data" and not an accuracy percentage.
Messy real payments. Marketplace payouts can arrive later and in batches. Our single matching window does not model this yet. It is a known limit for the next phase.
Accomplishments that we're proud of
A working matching prototype that turns raw records into the three-bucket alert in plain language. Matching rules simple enough to explain to a shop owner ("why was this flagged?") and to a judge. A design that stays honest about what it can and cannot see. A vendor-neutral approach: the matching logic does not depend on any one billing app.
What we learned
A problem has to be pinned to one real person before the solution means anything. The same sentence can be a strength or a weakness depending on whether it can be proven. "100% detection" became "3 of 3 planted cases". Simple rules can be more useful than complex ones when the user must trust and understand the output.
