If you run AP for a family-owned hospitality business with multiple locations, multiple departments, and vendor bills that need to be coded differently depending on what is on them rather than who sent them, this is written for you.
There is a version of AP automation that most software companies are selling. It looks like this: connect your accounting system, map your vendors to accounts, let the platform route and pay. Clean. Fast. Works great when your vendors are consistent, your departments are few, and your invoices are digital.
That version does not exist for a significant portion of the businesses actually running on QuickBooks Desktop in America. The ones with real operational complexity. Multiple locations. Multiple departments shopping from the same vendor for different purposes. Invoices that arrive by mail, by hand, sometimes written in pen by a vendor who has been doing business the same way for thirty years and is not about to change.
For those businesses, the automation problem is not payments. It is intelligence. Can the platform read a bill, understand what each line item represents, and code it correctly across multiple dimensions of the GL before it ever touches the accounting system? That is a harder problem. Most platforms do not solve it.
A small family-owned ski resort in Vermont came to MakersHub after trying to solve this in-house. They had built something on top of the Microsoft stack: SharePoint, OCR tools, a shared inbox. The person who led that effort was talented and deeply familiar with the operation. It still did not work. Not because of the people. Because the problem is harder than it looks from the outside.
What the Problem Actually Looks Like From the Inside
A hundred to a hundred and fifty bills a week in high season. Multiple food and beverage locations on the mountain, each one a different sub-account with the same vendor. A hardware store down the road where two different teams shop: sometimes for operating expenses, sometimes for capital expenditures, coded differently depending on what is on the line. A lodge that gets classed one way during ski season and a completely different way during summer wedding rentals. And roughly half the vendors are old-school operators who will never email an invoice. They mail it, hand it over, or write it by hand.
They had looked at Ramp four years ago and walked away. "It was too black and white." That is exactly right. Ramp sees a vendor and applies a rule. For a business where the coding decision lives in the line item, the delivery location, the season, and sometimes the handwriting on the invoice, a vendor-level rule is the wrong starting point architecturally.
The coding logic for a business like this has to operate at the line level and account for multiple variables simultaneously: ship-to address, vendor identity, item description, and GL dimension. Generic tools cannot do that. Custom builds on top of Microsoft OCR cannot do that reliably either. The document intelligence has to be purpose-built for the problem.
What MakersHub Actually Does Here
MakersHub extracts intelligence from the bill rather than just processing it. For a handwritten invoice from a local vendor, that means reading the document accurately regardless of format. For a food vendor delivering to multiple locations, that means understanding which location the delivery belongs to from the line-item context and routing it to the correct sub-account. For a hardware store purchase, that means distinguishing between the operating expense lines and the capital expenditure lines on the same invoice and coding them differently before anything syncs to QuickBooks Desktop.
The mapping rules work on an if-unless logic. A broad vendor rule applies unless a more specific line-item condition overrides it. The system learns the patterns over time. Vermont tax treatment, different rates for different purchase categories, gets applied correctly at the line level. Duplicate vendors and phantom items do not get created in QuickBooks during the sync.
The approval workflow gives the owner visibility into every transaction without requiring involvement in each one. A new person joining the AP team inherits a structured process rather than a manual one built around institutional knowledge that lives in one person's head.
This is the work. Not automating a payment. Extracting intelligence from a bill, coding its line items across multiple dimensions of the GL, and syncing it cleanly into QuickBooks Desktop. That is what we built MakersHub to do.
Here is what I shared on LinkedIn:
When my wife was 5, she fell off a ski chairlift. The incident nearly derailed a lifetime passion before it got started, but fortunately ended as no big deal. (The accident was her fault, not the resort's, which will become an important disclosure in a minute here...)
Worlds colliding is one the coolest and most unanticipated parts of building MakersHub for me. A great example happened last week:
My accident-prone wife grew up in Vermont and has been skiing ever since she could walk. The resort where she and all her siblings learned to ski became a MakersHub client last week!
It is a small family-owned Vermont ski area that came to us after trying to solve their AP problem in-house. They'd built something on top of the Microsoft stack — SharePoint, the OCR tools, a shared inbox — and it didn't work. Not because the people building it weren't capable & smart, the software engineer on their team who led the effort is very talented and deeply familiar with their operation. It didn't work because the problem is much harder than it looks.
Here's what that business actually looks like from a finance perspective. A hundred to a hundred and fifty bills a week in high season. Multiple food and beverage locations, each one a different sub-account with the same vendor. A hardware store down the road where the mountain ops team and the resort maintenance team both shop, sometimes for OPEX, sometimes for CAPEX, coded differently depending on what's on the line. A lodge that gets classed one way during ski season and a completely different way during summer wedding rentals. And roughly half the vendors are old-school Vermont operators who will never email you an invoice. They mail it, hand it over, or write it by hand.
Nothing generic handles this. They'd looked at Ramp four years ago and walked away. "It was too black and white." The coding logic for a business like this lives at the line-item level, and it depends on the ship-to address, the vendor, the season, and sometimes the handwriting on the invoice.
This is the work. Not automating a payment. Extracting intelligence from a bill that was written in pen, coding its line items across three dimensions of their GL, and syncing it cleanly into QuickBooks Desktop without creating duplicate vendors or phantom items along the way. That is what we built MakersHub to do, and it is the specific reason we exist.
Doing it for businesses that I have some attachment to is an immensely gratifying part of building MakersHub, and a pleasant surprise I never really anticipated.
For a family-owned operation that built something worth running over decades, the back office should be worthy of it. If your AP situation looks like the one described above, we would like to hear about it. makershub.com/get-started
Charley Howe, Co-Founder and President, MakersHub