About
Accountants building their own tools.
Finance Intelligence is built by chartered accountants. Everything here started out as work we were doing by hand, for clients, against deadlines. These tools exist because the people doing that work sat down and wrote out which parts of it never really needed a person.
Why us
We know which parts are rules.
A software company building for finance has to be told what the work is. They pick it up from a written spec, and that spec was put together by somebody describing the job rather than doing it. The gap between those two things is where most finance software goes wrong.
A practice does not have that gap. We know the TDS section on a payment is a rule, and the decision to pay early is a judgement. We know GST splits one way or the other on a fact you can look up, and that whether a cost belongs to this event or the next one is a conversation. We know a reconciliation is mostly matching, with a handful of lines that need someone to ask a question.
Knowing where that line falls is the whole product. Automating a rule is normal engineering work. Knowing exactly where the rules stop, and not guessing past that point, is the part you only get from having done the job.
Software that sounds confident about a judgement call is not better software. It is a problem with good manners.
What we believe
Rules belong in the database.
Most systems keep their rules in the app. The button is hidden, the form checks itself, the page checks your role. That is all real work, and none of it survives a second app, a phone, a scheduled job, or a script somebody wrote at eleven at night to fix a batch of records.
So we moved the rules a layer down. Who can read a voucher, who can approve it, what can still be edited and what is locked are all decided by the database itself. A small set of database functions is the only way to move a record along. The website is a nice way to use those rules. It has never been the thing enforcing them.
The test we hold ourselves to is a simple one. If you deleted the website tomorrow and handed a determined person a valid login, could they approve their own voucher? The answer has to be no, for a reason you can go and read in our code.
32
Voucher fields
Every one from the form you already use
2
Approvals needed
Never the same person twice
0
Ways to edit the history
Not for any role, at any level
1
Place your data sits
Mumbai, ap-south-1
The roadmap
One that works, then the next one.
The plan is a set of tools that covers the jobs your team does every month. The order is on purpose. Payments come first, because that is where approvals and proof matter most. The audit tool comes last, because it reads everything the others write.
- Voucher DeskPayments & approvalsLive
- Ledger ReconciliationBooks & closingLive
- GST ReconciliationIndirect taxOn the roadmap
- TDS ComplianceDirect taxOn the roadmap
- Invoice IntakeDocument captureOn the roadmap
- Audit CopilotAssurance & reportingOn the roadmap
2 of 6 are up and running today. The rest are marked in build or on the roadmap. We would rather say that here than have the conversation after you have signed something.
How we build
Four habits we stick to.
None of these are clever. They are just the ones we have found are expensive to break.
One thing at a time, and finish it
A half-built tool is worse than none, because somebody still has to do the work and now they have to check the software as well. Voucher Desk was deployed and being used before we started on the second one.
The rule goes into the database first
If we cannot write a rule down as code the database will enforce, we take that as a sign we do not understand the rule well enough yet to automate it.
Your existing paperwork wins
We match the format your team already works from, right down to the order of the columns. Whether people actually use a new tool comes down to how little has to change on the first day.
You see the real error message
When the database refuses something, the sentence it gives back is the sentence you read. Turning it into something friendlier but vaguer helps nobody at the end of a quarter.
Talk to the people who built it
Bring the awkward question.
You will be talking to someone who has both raised the voucher and written the rule that governs it. Ask us about the odd case that broke your last system.