Most multi-unit operators know their prime cost cold. Food cost runs 28-32% of sales at a typical QSR, labor another 25-30%, and together with paper and packaging they make up prime cost, 55-60% of revenue. Rent sits at 6-8% on top of that, closer to 8-10% once you load in property taxes, insurance, and CAM. Ask a Controller running 40 locations what prime cost looked like last week, by store, and they can usually tell you within a point.
That confidence comes from how those numbers reach the P&L in the first place. Rent is one lease, tied to one address, that never changes without a new agreement. Labor is mostly punched by people clocking in at the store they work, so hours land on the right P&L without anyone having to decide where they belong.
Food cost is the number in that set that's being estimated. Weekly flash reporting runs on theoretical food cost pulled from the ordering system, which is close enough to manage against and not the same thing as what actually hit the P&L. The real number doesn't exist until somebody has split the distributor invoices and coded every line. That happens at month end, under a deadline, by hand.
The rest of the P&L works the same way, and it's where most multi-unit finance teams lose visibility without realizing it.
The status quo: invoices that don't arrive pre-coded
Food cost reaches the P&L clean for a single-location business: one restaurant, one distributor account, one invoice that maps to one store. That breaks down the moment an operator is buying for 30 or 40 locations through the same account. One weekly Sysco or US Foods consolidated statement can run past 100 pages, cover every store in the group, and land in the corporate AP inbox as a single PDF with a single total.
The store identifier is on the document. That part is solved, and anyone who says otherwise hasn't opened one. What isn't solved is everything that has to happen after you read it.
The number on the invoice is the distributor's ship-to code, not the location code in your accounting system. Somebody maintains the mapping between the two, by hand, and it breaks every time a store opens, closes, changes distribution centers, or gets moved to a different account. New store, new ship-to, no mapping, and the cost lands in a suspense account or on the wrong store until someone catches it.
Then there's the half that the ship-to code does nothing for. Knowing a line belongs to store #012 doesn't tell you whether it's food, paper, chemicals, or smallwares. A case of gloves and a case of chicken hit different GL accounts and only one of them belongs in food cost. On a hundred-page statement that's several hundred line items, each needing a store and a category, and only the store half is machine-readable out of the box.
The same pattern shows up again, smaller, in controllable expenses: utilities, repairs, supplies, pest control, waste. Together these usually run 8-10% of revenue. A regional pest control vendor bills whatever stores are on their route, on whatever cycle suits their system. A commercial utility account can span a dozen meters across multiple sites. And once a year, a CAM reconciliation arrives covering every store in a landlord's portfolio, trued up against actual spend, that has to be pushed back to individual locations before anyone's occupancy line is right.
Every one of those invoices, food cost or controllable expense, has to be opened, read, split across the right stores, and coded to the right GL account before it means anything on a P&L. In most multi-unit finance teams, that work is done by one or two people, by hand, against a close deadline, for hundreds of invoices a month across dozens of vendors.
Why this breaks store-level reporting
The problem isn't just the manual labor. It's what the manual labor does to the numbers underneath it.
When invoice coding happens under time pressure, accuracy takes a back seat to speed. A line gets coded to whichever store and account is fastest to guess correctly, not necessarily the right one, so it can get posted before close. The correction happens later, if it happens at all, when someone reconciles the coding against what actually happened at each store. Until then, every per-store P&L that includes that invoice is provisional.
That has real consequences. A store manager can be judged on controllable expenses that were never actually theirs. A CFO reporting store-level performance to a franchisor or a lender is reporting numbers that are still being corrected weeks after the period closed. And because invoices look similar across stores that share vendors, the same manual process that causes coding errors also lets duplicate payments slip through, sometimes for months, before anyone notices.
None of this is a staffing failure. A one or two person AP team for 40 locations isn't understaffed because the people are slow. It's that the work itself, splitting and coding hundreds of multi-location invoices by hand every month, doesn't scale the way headcount does. Every new store adds a predictable amount of invoice volume. Nobody adds a fraction of an AP person for every five stores they open.
What visibility actually looks like when the coding isn't manual
The fix isn't a faster spreadsheet or a stricter close calendar. It's removing the manual step where store attribution and GL coding happen in someone's head.
That means reading a multi-location invoice the way a person would: resolving the ship-to code to your location, holding that mapping as stores change, and coding each line to the right account, whether it's a 127-page distributor statement or a utility bill covering a dozen meters. It means catching a duplicate invoice not because someone happened to notice a familiar-looking PDF, but because the system already knows what's been paid, to which vendor, for which store, and flags it before the payment goes out. And it means per-store P&Ls that are accurate as invoices land, not three weeks after close once someone has had time to go back and fix the coding.
This is what Quid was built to do. We built it around the reality that a single invoice in a multi-location business usually isn't one transaction, it's several hundred, and the software should be the one doing the sorting, not the two people on your AP team who are already behind.
Rent and labor are trustworthy because the data behind them is structurally simple, tied to one lease or one clocked-in shift. The goal is making food cost and controllable expenses just as trustworthy, not by asking your team to move faster, but by taking the manual coding step out of the process entirely.
Want to see what AI-driven invoice coding looks like for a multi-unit operation? Get in touch or reach out to Nikhil directly.