The challenge
The client is a mid-sized Indian manufacturer that handles a high volume of vendor invoices: about 6,000 a month when we started. Almost all of that work was manual.
Most invoices arrived as hard copies. The accounts team read each one and typed it into Tally by hand, and tracked where every invoice stood in Excel sheets. Many vendors used their own invoice formats, and some invoices were handwritten.
That made invoice handling slow and dependent on people. Every figure was keyed in by hand, and the status of each invoice lived in spreadsheets that had to be updated separately.
What we built
We started from FlowFin, our own finance operations platform, and customised it around how this manufacturer works: their vendors, their approval rules and their accounting system. The system they run today:
- Takes invoices in digitally. We set up a vendor portal and an email inbox for invoices, which replaced the hard copies that used to arrive.
- Reads every invoice, handwritten ones included. We trained FlowFin's invoice reader on the formats the client's vendors actually send, including handwritten invoices.
- Routes each invoice for approval. Approval workflows follow the client's own approval rules, so every invoice reaches the right people in the right order.
- Posts approved invoices to Tally. We connected FlowFin to Tally, so nobody types an invoice into Tally by hand.
- Tracks everything in one place. Every invoice can be followed from the day it arrives to the day it is posted, which replaced the Excel sheets.
Under the hood. FlowFin reads each invoice with a vision language model and gives every field it extracts a confidence score. Fields it is unsure of, such as a hard-to-read handwritten quantity, are flagged for a person to check, so anything uncertain is confirmed before the invoice goes for approval. Approvals run on FlowFin's workflow engine, which supports approval steps, conditions, automatic approvals and reminders; we configured it with the client's rules. Access is role based. Each vendor signs in to the portal with its own access code and sees only its own invoices and payments. Posted documents are never deleted: they can only be cancelled with a reason, and the change is recorded.
How we delivered it
- Customisation and integration (about four weeks). We set up the vendor portal and the email inbox, trained the invoice reader on the client's vendor formats, built their approval workflows and connected FlowFin to Tally. The system went live within those four weeks.
- Stabilisation and change management (about a month). After go-live, we worked with the accounts team and the client's vendors as they moved to the new way of working: invoices on the portal or by email instead of on paper, and tracking in FlowFin instead of in Excel. We adjusted the setup as real invoices came through.
Results
The client now handles about 9,000 invoices a month, up from about 6,000.
| Before | After | |
|---|---|---|
| Invoices handled a month | About 6,000 | About 9,000 |
| How invoices arrive | Mostly hard copies | Vendor portal and email |
| Entry into Tally | Typed by hand from each invoice | Posted from FlowFin after approval |
| Tracking | Excel sheets | One place in FlowFin |
| Handwritten and unusual formats | Read and typed by the team | Read by FlowFin, with unclear fields flagged |
Invoices now arrive in a form FlowFin can read straight away, follow the client's own approval rules and reach Tally without being typed in again.
Why it worked
- A working product as the base. Starting from FlowFin meant invoice reading, approvals and a vendor portal already worked, so the four weeks went into fitting them to this client.
- Trained on real invoices. The invoice reader learned from the invoices this client actually receives, handwritten ones included.
- The intake changed too. Moving vendors from paper to the portal and email meant invoices arrived ready to be read.
- Tally stayed. The accounts team kept the accounting system they know. FlowFin does the work between the invoice and Tally.