Solutions · Finance
Expense Automation
Receipts captured from any input, checked against policy and routed, with the claim built for the approver.
Why expenses are hard
Expense claims, as people describe them
Nobody complains about receipt capture. They complain about the drawer of thermal paper, the claim bounced for the third time, and the taxi that was paid for twice.
What you hear
I have a drawer full of receipts
A sales manager back from a fortnight of travel, a wallet of faded thermal paper, and a claim form that wants the GST number off each one. The claim is filed six weeks late, if at all.
What you hear
Finance bounced it again
A claim rejected for a missing receipt on one line, resubmitted, then rejected for the per-diem on another. Three round trips to settle ₹9,000, and a bad relationship between finance and everybody else.
What you hear
The same taxi was claimed twice
Once from a photo of the receipt, once from the card statement, by two different people who shared the ride. Nobody caught it because the two claims were approved by two different managers.
What is underneath
The employee is the data entry clerk
The person who spent the money is asked to type the merchant, date, amount and tax from each receipt into a form. The receipt already says all of that.
What is underneath
Policy is checked after the claim is filed
Limits, allowed categories and receipt rules are applied by the approver or by finance, after the employee has done the work. The rejection is the first time anyone tells them.
What is underneath
Receipts and entries live apart
The claim is in the expense tool, the entry is in the ledger and the receipt is in an email. A GST credit on an expense needs all three, and nobody can find the third.
How PTAS AI automates it
Read the receipt, check the policy, then ask the employee
The order is reversed. The receipt is read and tested against policy before the employee is asked to do anything, so filing a claim means confirming lines that already exist, and the first time a rule is broken is also the last.
-
01
Understand
DocPro reads each receipt as fields, from a phone photo taken at an angle, a forwarded hotel invoice or a card transaction feed: merchant and its GSTIN where printed, date, line items, total and the tax split. A creased receipt with a faded tax line comes back with that one field flagged for review, not with an invented number. Each field carries a confidence score.
A photo becomes an expense line
-
02
Decide
FinSuite builds the claim and runs your policy on it before anyone is asked to approve. Is the category allowed for this employee's grade? Is the amount inside the limit for that city and that category? Is a receipt required at this value, and is one attached? Has this merchant, date and amount been claimed before, by anyone? Is the GST on it claimable?
Policy is applied before the claim, not after
-
03
Act
Clean lines are categorised, coded to project or cost centre and routed to the approver your rules name by amount and category. The employee sees the claim already built and confirms it. Lines that break a rule are returned to the employee with the specific reason, before the approver sees anything, so the round trip happens once and early.
The employee confirms a claim rather than typing one
-
04
Verify
Approved claims post to the ledger with the receipts attached and go onto the reimbursement run, or are settled against the corporate card statement line by line. Every decision, automated or human, is on the audit trail, and the GST credit on each eligible line is recorded against the receipt that supports it.
The receipt is on the entry it produced
The workflow
What one receipt looks like once it is read
Receipts are the worst documents a finance team handles: small, creased, photographed badly and printed on paper that fades. The system treats poor image quality as a confidence problem on one field rather than a reason to reject the whole thing.
A creased receipt, photographed at an angle · Illustrative example
One faded field goes to a person. The other seven post. An invented tax amount would have been worse than a flagged blank.
Confidence, not rejection
A faded field is flagged for one person to settle. The rest of the receipt posts.
Policy, up front
Limits and rules run before the claim is filed, so the employee hears once.
Duplicates across people
The same receipt claimed twice is caught whoever submits it.
Key capabilities
Eight things the workflow has to do well
An app that photographs receipts moves the typing to a smaller screen. The policy checks, the duplicate detection and the posting are what take the work away.
Capture
Any input
A photo from the phone app, a receipt forwarded by email, a hotel folio as a PDF or a line from the corporate card feed. Each becomes the same structured line.
Capture
Receipt reading with a score
Merchant, GSTIN, date, items, total and tax read from poor images, with deskew and glare correction, and a confidence score on each field.
Checks
Policy and limits
Per-category and per-grade limits, city-based per diems, allowed merchants and receipt thresholds applied per line, with the rule that fired named on the line.
Checks
Duplicate detection
Merchant, date and amount compared with every claim and every card transaction, across employees, so a shared ride or a receipt and its card line are not paid twice.
Coding
Categorisation and coding
Expense category inferred from the merchant and the items, confirmed by the employee, and coded to project, client or cost centre from your rules and history.
Coding
GST on expenses
The merchant's GSTIN and the tax on the receipt checked, and the line classified as claimable or not under your rules, so eligible credit on travel and services is not left behind.
Flow
Approval routing
Routes by amount, category and project, with delegation and escalation. The approver sees the claim with the receipts and the policy result, not a form.
Flow
Reimbursement and card settlement
Approved claims posted to the ledger and placed on the reimbursement run by your cycle, or matched line by line to the corporate card statement so the card reconciliation is a by-product.
Approvals and exceptions
What a person actually sees
An approver should not be reading receipts. They should see a claim that has already passed policy, with the receipts attached, and only be asked about the lines a rule could not settle.
Returned to the employee
A policy breach
A dinner over the city limit, a category not allowed for the grade, a receipt missing above the threshold. The employee sees the rule and the line before anyone else does, and either fixes it or adds the justification the rule allows.
Held for a reviewer
A field the receipt could not settle
A faded tax amount or an illegible merchant name. One person confirms one value, with the image region shown. The rest of the claim does not wait.
Held for finance
A possible duplicate
The merchant, date and amount match a claim or a card line already in the system, possibly from a different employee. Both are shown together, and the decision is recorded on both.
Each hold lands with the person your rules name, states the rule or the field that stopped it, and escalates if nobody acts within the window you set. Approving from a phone is fine. Approving a line that broke policy without a recorded justification is not, and the workflow does not offer it.
Business outcomes
What changes, and how you would measure it
We do not quote hours saved before seeing your claims. We do agree the measures up front, on your numbers, so the decision to extend is based on something.
What changes
Days from spend to claim
Measure from the receipt date to the claim being filed. The number falls when filing a claim means confirming lines that were read from photos, not typing them.
What changes
Claims returned to the employee
The share of claims sent back after submission. It should fall close to nothing, because the policy result is shown before the claim is filed.
What changes
Duplicates stopped before payment
Receipts or card lines caught as already claimed, before reimbursement. Watch the number found after payment; it should fall to nothing.
What changes
Policy breaches, by rule
Lines held per policy rule, by department. One rule firing constantly usually means the policy is wrong, which is useful to know.
What changes
GST credit on expenses captured
Eligible input credit on travel, accommodation and services identified at claim time, against the receipt, rather than estimated at filing or forgone.
What changes
Card statement reconciled as it arrives
The share of corporate card lines matched to a claim and a receipt without a person. The unmatched ones are a short list, each with a cardholder's name on it.
Integrations
Your ledger and your payroll stay where they are
Approved claims post to the ERP with your accounts, projects and cost centres, and reimbursements go out through the payment run or payroll, whichever you use. Card feeds come in from the issuer where available.
SAP
ERP · API, IDoc or file
Oracle
ERP · API or file
Microsoft Dynamics
ERP · API
NetSuite
ERP · API
Tally
Accounting · XML import or ODBC
Zoho
Accounting · API
QuickBooks
Accounting · API
REST API
Any system · custom
Webhooks
Status events out
Four integration methods are possible: native integration, API integration, file or flat-file exchange, and custom integration. The systems named here are planning examples; which method applies to your instance, and whether your card issuer provides a feed, is confirmed during assessment rather than assumed. See FinSuite integrations for how postings and status flow.
Security and governance
Controls an auditor would recognise
Expense fraud is usually small and frequent, which is exactly what a rule catches and a tired approver does not. These are the controls built into the workflow, and the FinSuite security page has the detail.
Policy as configuration
Limits, categories, per diems and receipt thresholds are rules you can read, versioned and dated. Every held line names the rule, and a rule change applies from its effective date forward.
Segregation of duties
An employee cannot approve their own claim, a manager cannot approve a claim they are a party to, and finance cannot alter a claim without the change being recorded against the original.
A complete audit trail
Each claim carries the receipt images, what was read from them, the policy checks and their results, who approved what and when, and the posting and payment that followed. Exportable for internal and statutory audit.
Data handling
Receipt images and card data are held with role-based access, card numbers masked, and retained for the period you set. Cloud, private cloud or on-premise deployment where supported, with ISO/IEC 27001-aligned practices.
Product connection
The products that deliver it
DocPro reads the receipt. FinSuite runs the policy, the approval and the posting around it. The solution is the two configured to your expense policy and your approval bands.
FAQ
Questions finance and HR teams ask
Is this an expense app for employees?
There is an app, and the employee's part of it is small on purpose: photograph the receipt, or forward the email, and later confirm a claim that has already been built. The work this page is about happens around that, in the reading, the policy checks, the routing and the posting. If you already have an expense tool you like, the reading and checking can run behind it through the API.
What happens to a receipt the AI cannot read properly?
The field it could not settle is flagged, and the employee or a reviewer is asked for that one value, with the image region shown. The rest of the receipt proceeds. A faded tax amount should be a flagged blank, not a guess, because a guessed tax amount is worse than a missing one.
How does it handle per diems and mileage?
As rules rather than receipts. A per diem is calculated from the trip dates and the city band you define, and a mileage claim from the distance and your rate, and both are checked against the trip the employee logged. Neither needs a receipt, and the policy says so, so nobody is asked for one.
Can it reconcile our corporate card statement?
Yes. Each card line is matched to a claim and its receipt, and the card statement becomes a list of lines with a claim against them and a short list without. The ones without are routed to the cardholder, with the merchant and date shown, rather than to finance to chase.
How long does it take to go live?
The typical range is three to eight weeks, and it varies with how your policy is written today, how many entities and currencies you operate, and whether card feeds are available. The first two weeks are usually spent turning the expense policy from a document into rules, which tends to surface a few rules nobody had agreed on.
Keep reading
Related solutions and products
Finance Automation
Expenses as one of the queues that moves out of the close.
Read more →Payment Automation
The reimbursement run, with the checks done first.
Read more →Accounts Payable Automation
The same approach for supplier invoices.
Read more →DocPro Receipt Agent
How a creased receipt becomes a line, in detail.
Read more →Next step
Send us the worst receipts you have
Faded, creased, photographed in a moving taxi. If the reading holds up on those, the rest of the workflow is a policy conversation.