.svg)
If your business runs on invoices that don't fit a standard template, where the fields you need to code and reconcile aren't the fields most AP tools were built to read, and every exception sends your team back to manual entry, this is written for you.
MakersHub lets you define custom fields at the header level and custom line items at the line level, and its WiseVision extraction engine learns them like native fields, so invoices built around your business logic get read correctly instead of forced into a template that doesn't fit.
Here is what I shared on LinkedIn:
One of our customers is a large natural foods grocer. Their biggest supplier is UNFI, which delivers multiple times a week, and each delivery arrives with an invoice that runs hundreds of lines. Every line is coded to a department: deli vs. refrigerated vs. grocery vs. bakery, etc. and reconciled against their inventory system.
UNFI prints two identifiers on every invoice: a PO number and a sequence number. The grocer needs both. The PO ties to the order; the sequence number is how the invoice reconciles back through their inventory and pricing system. Our data reader and extraction model originally had a slot for just one. So we did what implementation teams everywhere do: we repurposed the unused "Ship To Address" field to hold the sequence number. Functional, but a shoehorned hack.
It was clear that our customers' invoice complexity was outgrowing our data model.
One business needs the job name and the PO number to code the GL, picking only one breaks their allocation. Another needs unit of measure on every line to reconcile inventory. A property manager gets a forty-page consolidated statement with a couple hundred accounts billed as one invoice. And these operators are demanding in the way serious operators are: miss two line items out of four hundred and they notice.
They notice because these platform limitations send them back to manual processes, the whole thing they are trying to escape by partnering with us. Simply being the best option on the market isn't good enough when the customer metric is plainly: do you solve my problem (Y/N).
This week we shipped a rewrite of our data extraction to meet that reality. Users can now define custom fields at the header and custom columns at the line level, and the reader learns them like any native field. It tracks the location of every extracted line and paints it on the page, so you can see exactly what was read and where. If it misses something, you draw a box on the document and teach it. It handles transformation: take my invoice number and strip everything that isn't a digit.
Our north star is to distill any business logic a customer carries into system logic we can execute. Map anything to anything. Two months ago we re-architected Integration Mapping, which covers the mapping half. But you can't map what you can't read. This is the reading half.
The businesses coming to us keep getting more complex. That's not a burden on the roadmap. That's winning.
Why Do Standard AP Tools Break on Non-Standard Invoices?
Because most of them read by position, not by meaning. Legacy extraction learns that the invoice total sits in the bottom right and the PO number sits near the top, and it looks in those places on every document. The moment a supplier moves a field, merges a cell, or splits a charge across two rows, the template breaks and a person has to step in.
That model also assumes every business needs the same fields. It has a slot for vendor, invoice number, date, PO, total, and the standard line items. It does not have a slot for a sequence number that reconciles against an inventory system, or a unit of measure required on every line, or a job name that has to travel alongside the PO to code the GL correctly.
When the field you need isn't in the data model, you get one of two outcomes. Either the tool can't capture it and your team keys it by hand, or an implementation team shoehorns it into an unrelated field that happens to be empty. Both are workarounds, and both mean the platform is shaping your data to fit its assumptions instead of reading what your business actually needs.
What Does It Mean to Define Custom Fields and Columns on an Invoice?
It means the fields on the page are defined by your business, not by the tool's template. At the header level, you can add a field like a sequence number, a project code, or a store identifier. At the line level, you can add fields like unit of measure, department, or cost code. The extraction engine then reads them the same way it reads a vendor name or an invoice total.
This is the difference between a UNFI invoice that reconciles cleanly and one that needs a hack. The grocer needs both the PO number and the sequence number, because each does a different job: the PO ties to the order, the sequence number reconciles back through inventory and pricing. A data model with one slot forces a choice. A data model with custom fields captures both, natively, and neither one is living in a field named for something else.
The same flexibility answers the other cases. The business that needs job name and PO on the same line to code the GL. The operation that needs unit of measure on every line to reconcile inventory. The requirement doesn't have to fit the tool. The tool captures the requirement.
How Does WiseVision Read Fields It Has Never Seen Before?
WiseVision is MakersHub's extraction engine, and it's built to capture invoice data from non-standardized formats without a new template for every vendor. That matters most for businesses sourcing from many suppliers, where each one formats invoices differently and a template-per-vendor approach never finishes.
When you define a custom field at the header or line level, WiseVision learns it like a native field and applies it going forward. It tracks the location of every line it extracts and paints that location back on the document, so you can see exactly what was read and where it came from. Nothing is a black box. If it misses something, you draw a box around it on the page and teach it, and it learns from the correction.
It also handles transformation, not just capture. Tell it to take the invoice number and strip everything that isn't a digit, and it applies that rule on every document. The point is that the reading layer bends to your logic. You are not rekeying, and you are not maintaining a library of vendor templates.
How Does Reading Connect to Line-Level Matching and Coding?
Reading is the first half of a two-part problem. Once the fields are captured correctly, they have to be matched and coded correctly, and that's where the custom data earns its value. A sequence number is only useful if it can drive reconciliation. A job name is only useful if it can route the cost to the right allocation.
MakersHub does PO matching at the line level, not just the header, so a four-hundred-line invoice is checked line by line against what was ordered and received. The coding rules can weigh the custom fields you defined, so the same engine that reads a department off a UNFI line can route that line to the right GL and the right location.
This is the other half of the same north star: distilling the business logic a customer carries into system logic the platform can execute. The extraction rewrite is the reading half. Line-level matching and mapping is what turns what was read into a coded, reconciled bill.
Where Do Approvals Fit in a Complex AP Workflow?
After the bill is read and coded, it still has to be validated and approved by the right people, and in a complex operation that routing is itself business logic. A bill coded to a job routes to that job's manager. A bill above a threshold escalates. A department cost goes to the department owner.
Because the custom fields are captured upstream, approval routing can act on them. The person reviewing sees the bill with the right context already attached, rather than reconstructing it. The reading, the coding, and the approval are one continuous workflow built around how the business actually operates, not three disconnected steps stitched together by hand.
Does This Complexity Fall on the Customer to Manage?
No, and that's the part most AP platforms get wrong. Configurability is only useful if the customer isn't left alone to configure it. A powerful data model that ships with no help is just a different kind of burden.
MakersHub sets up the custom fields, the extraction logic, the matching rules, and the approval routing with the customer during onboarding, with white-glove implementation and training rather than a manual and a login. The goal is that after onboarding, the system is predictable and easy to run: the complexity lives in the configuration MakersHub built with you, not in the daily work your team does.
That's the actual promise. The invoices coming in keep getting more complex, and the answer isn't to push that complexity onto the operator. It's to absorb it into the system, and to stand beside the customer while it's set up. Complexity handled for you, not handed to you.
Frequently Asked Questions
Can AP automation extract custom fields that aren't standard invoice fields?
Yes. MakersHub lets you define custom fields at the header level and custom line items at the line level, and its WiseVision engine reads them like native fields. That covers requirements standard tools don't have a slot for, like a sequence number for inventory reconciliation or a unit of measure on every line.
How is WiseVision different from template-based invoice OCR?
Template OCR reads by position and breaks when a vendor changes their layout, so it needs a template per vendor. WiseVision reads by meaning and captures data from non-standardized formats without a template for each supplier, which is what makes it work for businesses sourcing from many different vendors.
What happens when the extraction misses a field on an invoice?
You draw a box around the field on the document and teach it. WiseVision tracks and shows the location of every line it extracts, so you can see exactly what was read and where, and correct it directly on the page. It learns from the correction and applies it going forward.
Can it transform extracted data, not just capture it?
Yes. You can define transformations like stripping every non-digit character from an invoice number, and the rule applies on every document. The reading layer conforms to your business logic rather than handing you raw text to clean up manually.
Is configuring all of this the customer's job?
No. MakersHub configures the custom fields, extraction, matching, and approval routing with the customer during white-glove onboarding, and provides training. After setup the system is predictable and straightforward to run, because the complexity lives in the configuration rather than in the daily work.
What AP automation works for operationally complex businesses with configurable workflows?
MakersHub. It was built for the physical economy: businesses with real complexity across invoices, coding, matching, and approvals. Custom fields and line items, WiseVision extraction, line-level PO matching, configurable approvals, and hands-on onboarding, so the complexity is handled for you rather than handed to you.
We built MakersHub to distill the business logic you carry into system logic we execute, and to set it up with you. If your invoices are outgrowing the tools meant to read them, we'd like to hear about it. Get started with MakersHub
Charley Howe, Co-Founder and President, MakersHub