DocPro · Agent
Custom Document Agents
For the documents no standard agent covers: define the schema, show the agent your samples, set the validation rules.
Coverage
Custom document extraction for the paperwork no standard agent covers
Five standard agents read invoices, receipts, bank statements, identity documents and purchase orders. Everything else is a custom document extraction job: a document type you name, with a schema and rules written in your terms. Six examples, each with the fields that matter and the check that follows.
Legal
Contracts and rate agreements
Parties, term, renewal date, notice period, payment terms and the rate schedule, returned as fields so a later invoice can be checked against what was agreed.
Logistics
Lorry receipts
LR number, consignor, consignee, vehicle number, packages, chargeable weight and freight. Checked against the delivery challan and the contracted rate for the lane.
Operations
Delivery notes
Supplier, order reference, item, quantity delivered and whether the signature block is filled. The third leg of a match where the ERP holds no goods receipt.
Insurance
Insurance forms
Proposal forms, policy schedules and claim intimation forms as administrative fields: policy number, insured, period, sum insured, premium. The agent reads the form. Your claims team decides the claim.
Facilities
Utility bills
Consumer number, billing period, units, tariff, late fee and due date, per site, so a hundred electricity bills become one coded payment run instead of a hundred keyed entries.
Customs
Bills of entry
Bill of entry number, port code, HSN per line, assessable value, basic customs duty and IGST, so import duty lands on the landed cost of the shipment it belongs to.
What you define
What a custom document agent is made of
Every DocPro agent, standard or custom, is the same six things. On a standard agent we have already written them. On a custom agent you write them with us, in business terms, during onboarding. The right column uses a lorry receipt as the running example.
None of this is a template. A template says where a field sits on the page, and it breaks the day a transporter moves a box or buys a new printer. A schema says what the field is and how to check it, and the model finds it on the page by context. That is why a transporter you have never seen works on its first LR, and why a redesigned form is a review item rather than a rebuild.
Illustrative output
One lorry receipt, schema in, record out
The left side is the schema as it is written during onboarding. The right side is the record your workflow receives for one document. The transporter, identifiers and amounts are invented for this page and are not customer data.
The schema, as defined
The record, as returned (illustrative)
{
"document_type": "lorry_receipt",
"schema_version": 3,
"sender_id": "T-0412",
"lr_number": "SRT-2026-18307",
"lr_date": "2026-09-11",
"vehicle_number": "HR35AB4471",
"consignor": "Narnaul plant",
"consignee": "Pune depot",
"packages": 48,
"chargeable_weight_kg": 2140.0,
"freight_amount": 18500.00,
"confidence": {
"lr_number": 0.99,
"vehicle_number": 0.98,
"packages": 0.91,
"freight_amount": 0.99
},
"validation": {
"vehicle_number_format": "pass",
"packages_match_challan": "fail",
"freight_within_lane_rate": "pass"
},
"review": ["packages"]
}
How one is built
Samples, schema, run, review, tune
A custom agent is built on your documents rather than on a sample pack. This is the order we work in, and the last two steps keep running for as long as the agent is in service.
Samples
Ten to twenty real documents of the type, with the poor ones included: a faded scan and a form filled in by hand. We ask for the worst first, because the schema has to survive them.
Schema
The fields, their types, which are required and what each one means in your process, written with the people who handle the document today and in their words. Where a field feeds a downstream check, the check is written beside it.
Run
The samples go through the pipeline: classified, read, scored and validated against the rules as written. The output is compared with what your team knows is on each page, field by field. The differences are the work list.
Review
Fields below their bar, or failing a rule, reach a reviewer in the queue with the reason attached. Each correction is logged against the field and the sender. In the first weeks this queue is the most useful report you have.
Tune
A bar moved, a rule tightened, a note added for one sender. Every change is a versioned release of the agent, so a record always says which schema and rule set produced it. Tuning runs on a schedule rather than continuously, so behaviour does not drift.
In a workflow
A custom agent earns its place inside a workflow
Reading the document is rarely the whole job. The figure is a freight cost audit: the carrier's charge, the lane and weight from the LR, and the contracted rate from your transport system, compared line by line and held above a tolerance you set. The counts in the figure are illustrative.
Worked example — freight cost audit · Illustrative example
Three systems, four agents and one human gate above a value you set. None of that is a product feature — it is a workflow assembled from parts that already exist.
Lane from the document
Origin, destination and chargeable weight come from the agent, so the audit never waits for someone to read the LR.
Tolerance is yours
A line holds when the variance against the contracted rate crosses the figure you set, and the hold names the variance.
Written back
The result and any dispute land in the ERP and the transport system with the documents attached.
Limits
What a custom agent will not do
It reads what is on the page. It does not decide what the page means. A contract agent returns the notice period, the renewal date and the rate table; it does not say whether the clause is enforceable or whether to renew. A claim intimation form becomes fields; the claim is decided by your claims team. We would not automate that decision, and we say so before the schema is written.
Some documents are poor candidates. Free text with no stable fields, a type that changes shape every month, or one that arrives twice a year, does not repay the schema work. A page that only makes sense to one person with context the page does not carry, such as a handwritten site diary, is one we would leave with that person. We would rather say either of these at assessment than build an agent that spends its life in the review queue.
The first weeks carry a higher review rate than the steady state, because the rules have not yet met every sender. That is expected, and the queue is where the tuning comes from. If a process cannot tolerate a person in the loop during that period, start with a document type that can.
Controls
The same controls as every standard agent
A custom agent runs on the DocPro pipeline, so it inherits every control the standard agents carry. Four matter most on a document type you defined yourself.
Thresholds per field
Set during onboarding, visible on every record, changed only through a versioned release of the agent. A field below its bar does not pass unattended.
Rules you can read
Validation written in business terms, tested against your samples before it goes live, and reported per rule on every record so a failed check names itself.
Review with a reason
A held field reaches a named role with the score or the rule that stopped it. The correction is logged against the field, the reviewer and the sender.
Versioned schema and audit log
Every record carries the schema version and rule set that produced it. What the model returned, what a person changed and when are kept and exportable. Deployment is cloud, private cloud, or on-premise and air-gapped where supported.
Delivery is the same as for any other agent: documents in by REST, the record out by webhook or poll, in real time or as a batch, with a reviewed record arriving the same way an unattended one does. The DocPro API page has the detail, DocPro Integrations covers the routes into your systems, and DocPro Security sets out retention, access and deployment.
FAQ
Questions teams ask about custom agents
When do we need a custom agent rather than a standard one?
When the document is a different type from the five the standard agents read, with its own fields and its own checks. An invoice with a project code or a contract reference on it is still an invoice; those fields are added to the Invoice Agent schema during onboarding. A lorry receipt, a bill of entry or a policy schedule is a different document, so it gets its own agent.
How many samples do you need, and do they have to be clean?
Ten to twenty of each type is usually enough to write the schema and test the rules, and we want the poor ones included: scans, photos and forms filled in by hand. More senders means more samples, because the per-vendor notes come from seeing each sender's habits. Clean samples alone produce an agent that looks finished and is not.
Who writes the schema and the rules?
We do, with the people who handle the document today, in their words. A rule reads as a sentence a finance or operations lead can check: freight within the contracted lane rate, packages equal to the challan count. Nothing in the definition is code, and a change to a rule is a versioned release of the agent rather than a development ticket.
What happens when a sender changes its format?
Fields are located by context, so most format changes pass without anyone noticing. Where a change lowers confidence on some fields, those fields route to review and the log names the sender. If the change is permanent, a per-vendor note or a rule adjustment goes into the next tuning pass. There is no template to rebuild, because there was never a template.
How long does it take, and how is the output delivered?
A custom agent is built inside the same onboarding as any DocPro rollout, typically four to twelve weeks for a single workflow; an indicative range that varies with document variety, systems, approval design and deployment. The output is delivered the way every agent delivers it: structured JSON by API or webhook, in real time or as a batch, or by a file route scoped during assessment. A reviewed record arrives the same way an unattended one does.
Keep reading
Where to go next
DocPro API
How a custom agent's output reaches your system: submit, poll, webhook, and the reviewed record.
Read more →Document Data Extraction
The business problem, written as a solution rather than a product, across standard and custom document types.
Read more →Document AI
What OCR, layout understanding and extraction each contribute to reading a page, and where each one stops.
Read more →DocPro
The platform every custom agent runs on: the pipeline, the trust model and the five standard agents.
Read more →Next step
Bring the document no standard agent covers
The online test reads invoices and payment receipts today. For a lorry receipt, a bill of entry or a form of your own, send ten samples ahead of a demo and the session becomes a first pass at your schema.