.svg)
If you're evaluating a virtual card or fleet payments program for the rebates, and you're wondering why so much of your AP still feels manual even after you adopt one, this is written for you.
Virtual cards solve the payment, which was never the hard part of accounts payable. The hard part is producing a correct payable: reading the bill, knowing which entity it belongs to, splitting it the way the job cost demands, and routing it for approval. MakersHub does that upstream work, before any payment file exists.
Here is what I shared on LinkedIn:
I recently spoke at a summit hosted by one of the largest fleet payments companies in the country. A large part of their business is putting cards in the hands of companies that run trucks: HVAC vans, service fleets, construction equipment.
The mechanics are simple. A client's AP system produces a payment file. The provider runs that file against its enablement data, identifies which vendors will take a card, and issues a tokenized number locked to one merchant and one amount. The vendor runs it like any other transaction. The buyer earns a rebate.
It works, and the economics can be meaningful. Virtual cards are roughly 2% of AP transactions industry-wide, and typically plateau somewhere around 20 to 30% of spend. The remaining 70-80% is the opportunity everyone in the room is interested to solve.
The problem is that the model starts at the payment file. And for the customer, the payment file is the finish line.
I sat in on an onboarding call this week with a very large production homebuilder in the Pacific Northwest. One of their plats has 88 lots. Every lot is its own job in QuickBooks Desktop, and every dollar of cost sits in WIP against a specific lot until the house closes, because that's the basis that releases at the sale.
Then a mass grading invoice arrives. One vendor, one invoice, one amount, and it belongs to all 88 lots. Not evenly. Weighted by lot square footage.
Today, they calculate the allocation across 88 lots by hand. Then type 88 line items into QuickBooks, again, manually. Job, item, description, allocated amount, footing to the penny. Every time.
With MakersHub, that work disappears.
The problem with the virtual card model is that by the time any of this reaches a payment file, it is one row. One vendor, one amount, one remittance record. The card provider sees a clean line and makes a good decision about whether it can be paid on plastic. What they cannot see is that the line took 88 decisions to produce.
Paying is not the hard part. Paying is close to solved. The hard part is producing a payable that is correct–reading the bill, knowing which entity it actually belongs to, splitting it the way the job cost demands, routing it to the superintendent who has to say yes.
How Do You Allocate One Invoice Across 88 Lots Without Entering It 88 Times?
You capture the allocation logic once and let the system produce the split. A mass grading invoice arrives as one vendor, one amount, but it belongs to dozens of lots, weighted by square footage. The allocation isn't the judgment call, the weighting basis is. Once the basis is defined, the arithmetic and the data entry are mechanical.
Done manually, this is a recurring tax on the finance team. Calculate the weighted share for each lot by hand, then key a separate line for every lot into the accounting system: job, item, description, allocated amount, footing to the penny so the total matches the invoice exactly. On a plat with dozens of lots, one invoice becomes dozens of manual entries, and it happens every time a shared cost arrives.
MakersHub reads the invoice once, applies the allocation basis, and produces the split automatically. Every lot gets its correctly weighted line, coded to the right job, footing to the penny, without anyone typing the same invoice dozens of times. The finance team defines the rule. The system does the allocation.
Why Is Producing the Payable Harder Than Paying It?
Because paying is a single decision and producing the payable is many. By the time a bill reaches a payment file, it's one clean row: one vendor, one amount, one remittance record. A payment provider looks at that row and makes one good decision, whether it can be paid on a card. That decision is close to solved.
The row hides everything it took to create it. Reading the bill accurately. Knowing which legal entity it actually belongs to. Splitting it the way the job cost demands. Routing it to the person who has to approve it. A single line on a payment file can represent dozens of upstream decisions, and none of them are visible to a system that starts at the file.
This is the structural blind spot of payment-first AP. It optimizes the last step, the one that was already the easiest, and leaves the hard upstream work exactly where it was: manual, on the finance team, unowned by the software.
Why Don't Virtual Cards Cover Most of Your AP Spend?
Because acceptance is capped by what vendors will take. Virtual cards are a small share of AP transactions industry-wide and typically plateau around 20 to 30 percent of spend. The other 70 to 80 percent still moves by ACH, check, or wire, because those vendors won't or can't accept a card.
That ceiling is inherent to the model, not a rollout problem you can fix with better enablement. A rebate program only touches the slice of spend that runs on plastic. The majority of the payable volume, and nearly all of the complex, job-costed, multi-entity spend that actually consumes the finance team, sits outside it.
So even a well-run card program leaves most of the work untouched. The rebate is real on the spend it covers. It just isn't where the difficulty lives.
How Does WIP Allocation Work for Production Homebuilders?
Every dollar of cost sits in work in process against a specific lot until the home closes, because that's the basis that releases at the sale. For a production builder running each lot as its own job, the accuracy of that WIP balance depends entirely on every cost landing on the right lot, in the right amount, before the house sells.
Shared costs are where it gets hard. A mass grading bill, a shared utility trench, a common-area improvement: one invoice that belongs to many lots, split by an agreed basis like square footage. If that split is wrong, the WIP on every affected lot is wrong, and the cost basis that releases at closing is wrong with it.
Getting this right by hand is exactly the manual burden production builders carry. MakersHub captures the allocation basis and produces the weighted split automatically, so the WIP balance on each lot reflects reality without the finance team rebuilding the allocation by hand on every shared invoice. It's the same principle across the physical economy: distill the business logic the customer carries into system logic the platform executes.
What Should AP Automation Actually Solve First?
The payable, not the payment. The right sequence is to get the bill read correctly, coded to the right entity and job, allocated the way the cost demands, and approved by the right person. Once the payable is correct, paying it is the easy part, and you can pay it however makes sense, including on a card where the vendor accepts one.
MakersHub is built for that upstream work: reading the bill, multi-entity coding, line-level allocation and job costing, and approval routing to the person who has to say yes. It's the work that has to be right before a payment file means anything, and it's the work payment-first tools skip.
A rebate on the easy part is still worth having. It just isn't a substitute for solving the hard part.
Frequently Asked Questions
Do virtual cards replace AP automation?
No. Virtual cards are a payment method that earns a rebate on the spend vendors accept on a card. They don't read invoices, code them to the right entity and job, allocate shared costs, or route approvals. That upstream work is AP automation, and it's what produces the correct payable a card can then pay.
What percentage of AP spend can go on a virtual card?
Typically around 20 to 30 percent, because acceptance is capped by which vendors will take a card. The remaining 70 to 80 percent moves by ACH, check, or wire. That ceiling is inherent to the model, so a card program leaves most of the payable volume, and most of the complex spend, untouched.
How do you split one invoice across multiple jobs or lots automatically?
You define the allocation basis once, such as weighting by lot square footage, and the system applies it. MakersHub reads the invoice, produces the weighted split across every job, codes each line to the right lot, and foots to the penny, instead of the finance team calculating and keying each line by hand.
Can AP automation handle WIP job costing for production homebuilders?
Yes. Costs are captured against the specific lot they belong to, so the WIP balance that releases to cost basis at closing is accurate. Shared costs are split by the defined basis automatically, which keeps the WIP on every affected lot correct without manual reallocation.
Is the rebate from a virtual card program worth it?
On the spend it covers, the rebate is real. The point is that it applies to the easiest part of AP, the payment, and only to the portion of spend vendors accept on a card. It doesn't reduce the upstream work of producing a correct payable, which is where the difficulty and the manual effort actually sit.
What AP automation works for complex, job-costed, multi-entity spend?
MakersHub. It reads the bill, codes it to the right entity and job, allocates shared costs by your defined basis, handles line-level job costing, and routes approvals, the upstream work that has to be right before any payment method matters. Built for the physical economy, where the payable is the hard part.
We built MakersHub to solve the hard part of AP: producing a payable that's correct before anyone pays it. If your team is splitting invoices by hand across jobs, entities, or lots, we'd like to hear about it. Get started with MakersHub
Charley Howe, Co-Founder and President, MakersHub