A Vendor-Payment Approval Workflow App for a 120-Person Manufacturer

A 120-person auto-parts manufacturer near Pune was approving vendor payments over WhatsApp. The plant head would forward an invoice photo to the director, who'd reply "ok pay" — and accounts would release money against a PO nobody had matched. They'd had one near-miss: a ₹3.8 lakh duplicate payment caught only because a vendor honestly flagged it. We built them a vendor-payment approval workflow app in 6 weeks: multi-level approvals, PO-to-invoice matching, a tamper-evident audit log, two-way Tally sync, and three fraud gates. Here's how it's built. ## The answer in 60 words We replaced WhatsApp approvals with a web app where every vendor payment runs a fixed path: invoice uploaded, auto-matched to its purchase order, routed through value-based approval tiers, then synced to Tally only after final sign-off. Three fraud gates — duplicate-invoice detection, bank-account-change holds, and three-way PO matching — block the failure modes that cost them money. Build cost: ₹6.8 lakh, live in 6 weeks. ## Why off-the-shelf didn't fit Generic approval tools assume a clean, English-first, single-currency office. This client's reality: approvals happened on the shop floor in Marathi and Hindi, the PO data lived in Tally, and the directors wanted approvals on their phones without learning new software. An off-the-shelf workflow tool would have meant re-keying every PO, abandoning Tally as the source of truth, and training 120 people on a foreign UI. We've made this build-vs-buy call before — the logic mirrors our custom HRMS for a 400-person manufacturer, where off-the-shelf meant paying a tax in re-keying and lost fit. The deciding factor was the audit trail. Cyber-insurance and a forthcoming statutory audit both wanted a tamper-evident record of who approved what payment and when. WhatsApp screenshots are not an audit trail. That requirement alone ruled out the informal status quo. There was also an adoption reality off-the-shelf tools ignore. The directors approving large payments are not software people — they wanted to tap one notification and see the invoice, the matched PO, and the approval history on one screen, in language they read fluently. A generic tool's multi-tab, English-only interface would have quietly pushed them back to WhatsApp within a week, and the whole control would have collapsed. We designed the approval screen around how they already behaved, not around how the tool wanted them to behave. Adoption is a control: a workflow nobody uses protects nothing. ## Why the audit log had to be tamper-evident, not just a log A plain activity log records what happened. A tamper-evident log proves it wasn't changed afterward — and for a payment system, that distinction is the whole point. An ordinary log table can be edited by anyone with database access, which means it can't answer the question an auditor or an insurer actually asks: "can you prove this approval history is the original?" By chaining each record to a hash of the one before it, any later edit breaks the chain and becomes detectable. The client didn't ask for blockchain or anything exotic — just a guarantee that the record of who approved a ₹5 lakh payment can't be quietly rewritten if something goes wrong. That guarantee is cheap to build and disproportionately valuable when a dispute or an audit lands. ## The client, in specifics - Sector: Auto-parts manufacturing (stamped components, tier-2 supplier) - Location: Industrial belt near Pune, Maharashtra - Size: 120 staff, ~₹90 cr revenue, roughly 180 vendor payments a month - Stack on day 0: Tally Prime for accounts, WhatsApp for approvals, email for POs - The trigger: A ₹3.8 lakh duplicate payment, caught by the vendor, not the system - The mandate: The director gave the finance head ₹7 lakh and 6 weeks before the audit ## What we built (the four pillars) ## The three fraud gates (where the real value is) The approval UI is the visible part. The fraud gates are why the project paid for itself. Each one blocks a specific way money walks out the door. ## The DIY walkthrough: how we'd build this, step by step If you're scoping a similar build, here's the sequence and the verification at each stage. ## The stack we used

Layer	Choice	Why
Frontend	Next.js + React	Works on directors' phones and accounts' desktops from one codebase; fast to ship.
Backend	Node.js API	Same language as frontend; the team maintains one stack.
Database	PostgreSQL	Transactional integrity for money movement; append-only audit table with a hash chain.
Tally integration	Tally HTTP/XML connector	Reads masters and POs, writes payment vouchers back — keeps Tally as source of truth.
Notifications	WhatsApp Business + email	Approvers get a notification where they already are; the approval still happens in the app.

## When NOT to build this Skip a custom build if your payment volume is small and your team is tiny — under maybe 30 payments a month with two people, a shared spreadsheet plus a written two-person sign-off rule may be enough, and a ₹6–7 lakh app is over-engineering. Skip it if you're willing to live inside your accounting suite's native approval module; some ERPs have a workable one, and bending your process to fit it is cheaper than custom. And skip it if leadership won't actually follow the workflow — the best audit log in the world is useless if the director keeps approving payments over WhatsApp anyway. The control is only as strong as the discipline behind it.

• Approval matrix documented and signed off — no "it depends" rows
• Tally vendor masters and POs syncing into the app
• Value-tiered approval routing working and editable by finance
• Three-way PO + goods-receipt + invoice match enforced
• Duplicate-invoice detection blocking repeats automatically
• Bank-account-change hold freezing payments for re-verification
• Append-only audit log with hash chain; edits rejected
• Approved payments posting back to Tally as vouchers
• UAT done in the approvers' own languages before go-live

## The outcome Six months on: zero duplicate payments, every payment now carries a complete approval trail, and the statutory audit cleared the payment process without a single follow-up query. The finance head's words — "I can finally answer 'who approved this' in ten seconds, not ten emails." The director still gets a WhatsApp notification, but he now taps through to approve inside the app, where the fraud gates run before any money moves. As Manvi, who led QA on this build, puts it: a payment app isn't done when it pays correctly — it's done when it refuses to pay incorrectly, every time, under every edge case the test suite can invent. That framing is why most of our build effort went into the gates and the audit log, not the happy path. We've built the same shape of control-heavy internal app across sectors — the architecture echoes our custom CRM for a 14-branch diagnostics lab, where audit trails and role-based gates were equally central. Our CRM and internal-tools team treats the audit log as a first-class feature, not an afterthought, and you can see the same rigor in Radiant Finance. For the founder's take on why we build these in-house rather than reselling generic tools, Vivek Singh's blog covers the build-vs-buy philosophy. Worth a sanity check: finance and controllership threads on r/IndiaTax regularly debate vendor-payment controls, and the bank-account-change fraud we gated against shows up there often enough to confirm it's not a rare edge case. ## FAQ ### Why not just use an off-the-shelf approval tool? Generic tools assume clean, English-first, single-system offices. This client's POs lived in Tally, approvals happened in Marathi and Hindi on the shop floor, and the audit needed a tamper-evident trail. Off-the-shelf meant re-keying every PO, dropping Tally as source of truth, and training 120 people on a foreign UI. ### How long does a vendor-payment approval app take to build? For a mid-size manufacturer with Tally integration, roughly 6 weeks from discovery to go-live: one week mapping the approval matrix, one wiring the Tally read sync, two building routing and the three-way match, one for the audit log and fraud gates, and one for write-back, testing, and launch. ### What is three-way PO matching? Three-way matching compares the invoice against its purchase order and the goods-receipt note before payment. Quantity and rate must agree within a tolerance. If any leg is missing or mismatched, the payment is blocked. It stops payment for goods never received or for amounts above what was ordered. ### Which fraud gate matters most? The bank-account-change hold. The costliest vendor fraud in Indian SMBs is usually a real vendor's invoice paid to an attacker-controlled account after a compromised email — not a fake invoice. Freezing any payment when a vendor's bank details change, and verifying by phone to a known number, blocks that attack. ### Does the app replace Tally? No. Tally stays the source of truth. The app reads vendor masters and purchase orders from Tally and writes approved payments back as vouchers. Accounts never re-key data, and the books always match the app. The app handles the approval workflow Tally doesn't. ### What does an app like this cost? This build was roughly ₹6.8 lakh for a 6-week engagement with Tally integration, three fraud gates, and a tamper-evident audit log. Cost scales with the number of integrations, the complexity of your approval matrix, and whether you need mobile apps beyond a responsive web app. ### How do you make the audit log tamper-evident? We use an append-only table where each record includes a hash of the previous record, forming a chain. Altering any past entry breaks the chain and is detectable. Combined with user and timestamp on every action, it gives an auditor a record that can't be quietly rewritten.