Automated PDF form filling
Tavnit fills fillable PDF forms from data extracted across several source documents at once. A declaration can be populated from an invoice, a packing list and a bill of lading in one pass, with a person approving the values before the filled PDF is issued.
Why this is painful
A surprising amount of office work is copying values from documents you received into a form somebody else requires. Customs declarations, insurance forms, grant applications, regulatory returns — the information already exists, spread across three or four PDFs, and a person moves it by hand.
It is also where errors are least forgivable. A transcription slip on a form that goes to an authority is a rejection or a penalty, not an internal correction.
What to extract
| Field | Why it needs care |
|---|---|
| Source document set | One slot per source flow. The form fills once every required slot has a completed run. |
| Field mappings | Which extracted field populates which PDF field. Configured once per template, reused every time. |
| Cleaner outputs as sources | A mapped value can come from a Cleaner rather than raw extraction, so converted or computed values land in the form. |
| Human-fill fields | Values nobody extracts — a reference number, a signatory — supplied at approval time. |
| Multiple templates | One set of source documents can fill several different forms in the same pass. |
What makes form filling hard
The data is spread across documents, not sitting in one
This is why generic document tools do not solve form filling: they extract from one file at a time. Filling takes one run per source flow and populates the form from all of them together, so weights from a packing list and values from an invoice reach the same output.
Documents arrive in whatever order they arrive
You rarely receive the full set at once. A fill stays open, collecting runs as documents arrive, and fires when every required slot is satisfied. Files uploaded without saying which slot they belong to are classified and routed automatically, and anything unmatched can be assigned by hand.
Some fields are never in the source documents
Every real form has values that exist nowhere upstream — an internal reference, a declarant name, a signature block. Those are human-fill fields, supplied at the approval step, which is also the natural point to correct anything the extraction got wrong before the PDF is issued.
How the pipeline handles it
- Flows — One flow per source document type; the form draws from all of them at once.
- Cleaners — Converts and computes values so what lands in the form is already in the required unit or format.
- Human in the Loop — Approval before issue, with corrections and human-supplied fields captured at the same step.
- Email Integration — Source documents forwarded to an address feed the fill without anyone opening the app.
Common questions
- Can one form be filled from several documents?
- Yes. Each source document type gets its own slot, and the form is populated from all of them together — which is the normal case for declarations and claims.
- What about fields that are not in any document?
- Those are human-fill fields, entered at the approval step alongside any corrections, so the final PDF is checked before it is issued.
- Can one set of documents fill more than one form?
- Yes. A configuration can hold several templates, and every one is filled from the same set of runs in a single pass.
Other document types
Try it on one document
Build a flow, send a real form filling through it, and see what comes back. Free credits to start.
Start free