Voucher Desk
Payment vouchers with two approvals built in. Nobody can approve their own voucher, and nobody can approve the same one twice.
You can use this today. Sign in and it is there, with the rules running behind it.
The case for it
The approval steps are not just screens in an app. They are rules inside the database, so they hold whether the request comes from the website, from a script, or from anywhere else.
What it does
The specifics.
Every line here is something it does today. If it were only planned, it would be on a page marked as planned.
All thirty-two fields from the voucher your team already uses, so the printed page looks the way it always has.
Two approvals from two different people, and neither of them can be the person who raised it. The database checks this, not the browser.
Voucher numbers are handed out when you submit, in the form FI/CHAPTER/25-26/0001. One run of numbers per chapter per financial year, and nobody types them by hand.
The database works out the totals itself, so the figure on screen is the figure on record.
GST is sorted for you. CGST and SGST inside a state, IGST between states, never both at once. Checked before you can submit.
Every step is added to a history that nobody can edit or delete, including the owner of the account.
PDFs you can search, and an Excel export with the same thirty-two columns your team already works from.
Where it fits
What goes in, and what you get back.
Takes in
Invoice, event, chapter, payee, amounts
The agent
Voucher Desk
Gives back
Numbered voucher, PDF, Excel, full history
Ends up as
A record with its full history
Whatever it produces ends up as a proper record with its history attached, not as a message in a chat window. You get something your reviewer already knows how to check.
It is running. Go and use it.
Sign in and it is there. If you would rather somebody showed you round first, we are happy to do that instead.
You can use this today. Sign in and it is there, with the rules running behind it.