Name only the invoice fields you post, match destination keys, and keep line items honest so vendor layout chaos does not break your parser. Name only the invoice fields you post, match destination keys, and keep line items honest so vendor layout chaos does not break your parser.
Create your first parser in minutes. No code, no setup calls.
Authorize Parsedit from Zapier, map Upload Document or New Parsed Document to a parser, and manage connections from the Integrations page.
Vendor PDFs will not standardize for you. Your schema can. A parser schema is the contract between messy files and clean destinations: the field names, types, and line-item shape you expect every time.
Get the contract wrong and reviewers drown in unused boxes. Get it right and new vendors mostly fit without a rebuild.
Schema design checklist for invoice parsers.
List where approved data goes in the next 90 days:
Those names win. Rename template fields to match. Parsedit templates are starting points you edit with Edit template. Docs: Document templates.
For most AP staging sheets:
| Field | Why |
|---|---|
| vendor_name | Match / create vendor |
| invoice_number | Dedupe and audit |
| invoice_date | Period posting |
| due_date | Cash planning |
| currency | Multi-currency AP |
| subtotal | Footing checks |
| tax | Tax posts |
| total | What you pay |
| po_number | Match when required |
Add remittance email, payment terms, or bill-to only if someone uses them weekly. Optional forever-fields become review noise.
Ask one question: do we post or analyze line detail?
Fighting a huge line-item table for a totals-only process is how pilots die. Deep dive: Capturing invoice line items.
Prefer explicit types for dates and numbers so destinations do not get 01/02/03 ambiguity or $1,234.00 strings when they want 1234.00. During review, normalize once; do not rely on sheet formulas to clean every row forever.
Upload 8–12 real files before you freeze the schema:
Adjust field names after you see repeated misses. PDF text selection covers one-offs; template edits cover patterns. Review guide.
If PO fields regularly appear beside invoices, do not cram PO-only columns into the invoice schema. Use packet splitting and, when intake volume justifies it, separate parsers for POs. Document packets.
Template changes apply to future uploads. Old documents keep the fields they were extracted with; you can still edit values in review. Communicate schema changes to anyone mapping Zapier or webhooks.
Create an Invoices parser, trim the template, run real samples, then connect Sheets or accounting. Afternoon setup: Document extraction pipeline guide.
snake_case keys that match sheet headersinvoice_number not inv#vendor_name over supplier unless your ERP says otherwiseConsistency across parsers helps anyone building Zapier maps or webhooks.
Do not leave zombie fields “just in case” for a year.
Before freezing v1, spend fifteen minutes with whoever owns the destination:
That meeting prevents three parallel naming schemes.
You started from a full invoice template with 35 fields. Reviewers ignore 20 of them.
Schema design is subtraction as much as addition.
Useful schema guides name concrete fields, show a trimmed list, and warn against universal invoice ontologies. That is what practitioners bookmark.
Should field keys be pretty or stable? Stable and match the destination. Pretty labels can differ in the UI if your tool allows; Parsedit focuses on template field identity for mapping.
How often should we revise the schema? After the first week of real volume, then only when a destination or posting policy changes.
What about vendor-specific fields? Add a field when at least a few vendors need it weekly. Otherwise keep it in notes outside the parser.
Trim the template, run ugly samples, then lock headers. Start free.