DocPro · Agent
PTAS DocPro Receipt Agent
Phone photos, scans and forwarded mail all become structured expense lines, with merchants resolved against your vendor master.
Input
What the Receipt Agent reads
Receipts are the worst-quality documents in finance and the most numerous. Thermal paper fades, phones shoot at an angle, and half of them arrive as a forwarded email with the receipt somewhere in the thread.
Reads
Phone photos
Shot at an angle, in a car, under a restaurant lamp. Perspective and glare are corrected before reading rather than treated as a reason to reject.
Reads
Thermal till receipts
Faded print is read as far as it survives. Where the ink has gone, the field is returned blank with a flag, not guessed.
Reads
Digital receipts
Ride, food and travel app receipts forwarded as email or PDF, with the merchant and the trip or order reference picked out.
Reads
Hotel folios and restaurant bills
Multi-line bills with room, food, service charge and tax on separate lines, kept as lines so policy checks can run per item.
Reads
Fuel and toll slips
Small, low-contrast slips with litres, rate and amount, plus the location and vehicle number when they are printed.
Reads
Foreign receipts
Currency read from the receipt and returned as a code. Conversion is left to your expense policy and your rate source.
Output
What comes back for each receipt
Merchant, date, totals, tax and a category, with a score on each. The figure shows the usual case: most fields clear, one does not.
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.
Merchant resolved
Trading name matched to your vendor master, with the ID.
Tax split
Gross, net, tax, tip and service charge as separate values.
Category assigned
From the merchant and the lines, using your own scheme.
Validation and confidence
Policy checks before the claim
A receipt is a claim waiting to happen. The agent runs the checks your expense policy already states, so a reviewer sees exceptions rather than every claim.
Confidence on a receipt is about the image more than the layout. A sharp photo of a printed bill clears every field; a faded thermal strip clears the merchant and the total and loses the tax line. The scores say which, field by field, so a blurred tax amount does not drag a clean total into the queue with it.
Review is a control you set, and on receipts it is usually set loose. Most teams hold the amounts to a high bar and let categories through at a lower one, because a wrong category is cheap to fix at month end and a wrong amount is not. Whatever you choose, the reviewer sees the field and the reason, and the correction is logged against that field. A receipt in the queue is the policy working, not the agent failing.
Illustrative output
One receipt, as the expense system receives it
The same creased cafe receipt as the figure above. Merchant, date and amounts are invented for this page and are not customer data.
On the receipt
Returned (illustrative)
{
"document_type": "receipt",
"merchant_name": "Kanti Sweets & Cafe",
"vendor_id": "V-2041",
"receipt_date": "2026-08-22",
"currency": "INR",
"total_amount": 1840.00,
"tax_amount": null,
"payment_method": "card",
"expense_category": "client_entertainment",
"capture_channel": "phone_photo",
"confidence": {
"merchant_name": 0.97,
"receipt_date": 0.96,
"total_amount": 0.98,
"tax_amount": 0.41,
"expense_category": 0.89
},
"validation": {
"duplicate_check": "clear",
"policy_limit": "within",
"date_window": "pass"
},
"review": ["tax_amount"]
}
Downstream
After the receipt is read
An expense line is not an outcome either. These pages cover what happens to it once it exists.
Expense Automation
01The solution page: claims, policy checks, approval and reimbursement.
FinSuite AP Automation
02Where approved expense lines are posted alongside the rest of payables.
DocPro API
03Submit from your own expense app and receive the line by webhook.
FAQ
Questions Teams Ask
Can it read a receipt photographed badly?
That is the normal input, so yes. Skew, glare, shadow and partial crop are corrected before anything is read, and image quality shows up as lower confidence on the affected fields rather than as a rejected document. A person sees the fields the agent could not settle, not the whole receipt again.
What about receipts where the print has faded?
Read as far as the surviving print allows, with the fields that have genuinely gone reported as missing rather than guessed. For expense work that distinction matters: an invented tax amount is worse than a flagged blank, because it posts.
How does it catch the same receipt claimed twice?
On merchant, amount and timestamp together rather than on the image, so the same receipt photographed twice from different angles is still recognised as one transaction. Claims by two different people against the same receipt surface the same way, with the earlier claim referenced.
Does it apply our expense policy?
It applies the parts of the policy that can be stated as a rule: limits by category, date windows, required fields such as a tax number above a threshold. It flags; it does not decide. Whether an over-limit meal is approved is a decision for the approver your workflow names.
Which capture channels are supported?
Phone photo from an expense app, email forward to a watched mailbox, flatbed scans of a batch, bulk upload of a folder, or the API from your own system. Each channel runs the same extraction and the same checks, so the output does not depend on how the receipt arrived.
Keep reading
Related Capabilities
DocPro
The platform this agent runs on: the workflow, the trust model and the other five agents.
Read more →DocPro Invoice Agent
The same discipline on the higher-value document.
Read more →Expense Automation
The claim workflow this agent feeds.
Read more →Custom Document Agents
For the slips and forms that are not receipts.
Read more →Next step
Send the shoebox
Upload one receipt now, photographed the way your team actually photographs them. For a demo, send a month of them.