Convenience Store Back Office: Keep PDI or Petrosoft, or Build Your Own?

When is off the shelf genuinely the right call here?

Buy if you run eight or fewer sites, one fuel brand, one point of sale (POS) platform, no foodservice programme, and your growth plan is organic. PDI CStore Essentials, Petrosoft CStore Office and Modisoft all handle that operator properly. They do fuel reconciliation, they do price book, they do accounting posting, and at that scale a build would be automating a process that has not yet strained. That is the honest answer for a large share of operators reading this, and it is the one we give on first calls.

Buy also if your real bottleneck is that nobody reads the reports you already have. New software does not fix an unread report. It produces unread reports at higher cost, on a longer timeline, with your name on the project. If your district managers are not opening the variance report that already exists, spend the money on somebody whose job is to open it.

And buy the parts of the stack that are genuinely solved. The register platforms themselves, meaning Gilbarco Passport and Verifone Commander, are not things any operator should reconsider. Neither is your accounting system, whether that is Sage Intacct or QuickBooks. Neither is electronic invoicing from a wholesaler like Core-Mark or McLane, which arrives clean and needs no help from you.

The honest test is whether you can name a number you are losing. Fuel variance you find on Wednesday, promotional allowances that never arrived, cost increases discovered a quarter late. If you cannot put a figure on any of them within a week of measuring, you do not yet have the problem this page is about.

When does a custom build actually pay off?

Build when three or more of these are true. You are over fifteen sites. You acquire stores, so you inherit whatever register platform the seller had. You run manufacturer programmes worth five figures a month. You have already paid for a custom report package or an integration consultant on top of your licence. And your controller maintains a spreadsheet the whole company depends on.

That spreadsheet is the specification, and it is the most reliable signal in this category. It exists because the packaged tool assumes one clean feed and you do not have one. Nine sites on Passport, six on Commander, two on older Ruby2 registers, four tank gauges of one family and the rest another, three sites on a jobber who emails bills of lading as photographs taken on a phone. Off the shelf back office wants a uniform estate. Acquisition does not produce uniform estates.

The second reliable trigger is direct store delivery paper. Electronic invoicing from a large wholesaler is fine. The problem is the forty other vendors: the bread route, the beer distributor, the ice company, the energy drink representative who rearranges your cooler and leaves a handwritten credit. The packaged answer is to get those vendors onto electronic invoicing, and they will not go. It is a paper problem rather than a software problem, which is exactly why it has stayed unsolved.

In discovery at a 34 store operator we timed the consequence: roughly 61 hours a month of pure invoice keying plus about 9 hours of district manager time driving paper around. Afterwards that became about 6 hours a month of exception review, and cost increases started getting caught the day they happened rather than the following quarter. Your numbers will differ, and you can measure them in a week.

How do they compare on the things that matter in this industry?

The differences are concrete and every one is checkable in a demonstration with your own data.

• Mixed fleet handling. Packaged back office expects one export shape. A chain built by acquisition has several, and older registers behave differently from current ones. This is the configuration ceiling most multi site operators hit first, and it is why a custom report package usually appears within two years of signing.
• Fuel variance timing. Both approaches reconcile register movement against tank gauge readings and deliveries. The question is when. A bookkeeper working from a printed gauge report two days later cannot catch a weeping pump seal. Polling the gauge directly and alerting a fuel manager by text at a threshold he sets can.
• Allowance reconciliation. Packaged tools generate the scan data submission file. Almost none of them reconcile, line by line, what the manufacturer actually paid against what your promotion model expected. That gap is the item nobody sells you and is often what pays for the project.
• Lottery as physical inventory. Instant tickets are bearer paper tracked by pack and book. Most back office treats lottery as a department total, so a missing book surfaces at the weekly settle rather than at the shift close.
• Transaction level journal analysis. Standard reporting gives cash over and short by shift, which is a lagging summary. Scoring a cashier against their own history and their peer group on the same daypart requires the whole fleet's journal in one place.
• Payment scope. Whichever route you take, the correct design never touches the payment path. Staying outside cardholder data scope is dramatically cheaper in engineering, hosting and audit than building inside it.
• Data portability. Ask any incumbent how you extract price book, cost history and vendor master as data rather than as reports. You will need it whether you migrate or not.

What does total cost of ownership look like at your scale?

From Digital Heroes delivery experience, a focused first release covering one or two of the real leaks across the whole fleet runs $60,000 to $130,000 over twelve to sixteen weeks. A full platform replacing the back office across fuel, price book, invoices, lottery, labour and accounting posting runs $150,000 to $400,000 phased over six to twelve months. Fuel reconciliation on its own, including bill of lading extraction, is roughly $45,000 to $70,000 depending on how many tank gauge families you carry. Invoice capture on its own is $35,000 to $60,000 over eight to ten weeks.

Each additional register platform after the first adds roughly $8,000 to $18,000, because the first one establishes the polling, parsing and reconciliation layer the others reuse. Older registers cost more, and tank gauges needing a serial to network bridge bring hardware and a site visit rather than only software. A 24 store chain across three register platforms taking both fuel and invoices lands near $128,000. A ten store chain on one platform taking invoice capture only lands nearer $62,000.

Running costs are modest but not zero. Infrastructure is $400 to $1,000 a month for a fleet of this size, scaling with transaction and document volume rather than head office users. Document extraction carries a per document inference cost that is small individually and real across forty vendors and twenty four stores, so model it against invoice count. Support and enhancement runs 12 to 18 percent of build cost a year, and you should ask specifically about cover outside office hours, because a store that cannot close a shift at eleven at night will call somebody. Then two standing items: manufacturer programme rules and state lottery reporting requirements change on schedules that are not yours, so treat both as maintenance rather than feature work.

What does the hybrid look like, and when is it the honest answer?

For most operators between eight and twenty sites, the hybrid is the right answer and full replacement is not. Keep PDI or Petrosoft as the back office of record. Build the one or two pieces it structurally cannot do for your estate, and let them feed it.

The clearest example is invoice capture. A clerk photographs the paper at the counter while the vendor is still standing there, extraction pulls vendor, invoice number, date and every line with product code, quantity and unit cost, the system matches lines against the price book and flags cost changes above a threshold you set, and approved invoices post as a batch. That sits beside your existing back office rather than replacing it, costs $35,000 to $60,000, and empties the drawer. Operators consistently see the fastest return here.

The second example is fuel variance alerting. Keep whatever monthly reconciliation your incumbent produces for the record, and build the daily loop that polls the gauge and the register export, parses the bill of lading, and texts a threshold breach to a named person.

The sequencing rule is blunt: pick the leak, not the category. Operators who scope a full back office replacement in release one spend nine months before a clerk touches anything. Operators who scope one leak have working software in a store inside four months and fund the rest from what it saves. When you do migrate, run parallel for four to eight weeks and time the incumbent cancellation to your renewal date rather than your launch date, because chains that switch the old system off at go live turn it back on within a fortnight.

Which should you choose, by operator size and stage?

Up to eight sites, one platform, organic growth: buy. PDI CStore Essentials, Petrosoft CStore Office or Modisoft. Nothing else on this page applies yet.

Nine to fifteen sites, one or two platforms: buy the back office, build the invoice pipeline. This is the population where the accounts payable clerk and the district manager's Monday loop are the measurable cost, and where $35,000 to $60,000 removes it without touching anything else.

Fifteen to forty sites, mixed fleet from acquisitions: build the first release across fuel and invoices, keep the incumbent running underneath until it has proved itself. Expect $60,000 to $130,000 and expect the platform count rather than the store count to set the number.

Forty sites and up, with manufacturer programmes worth five figures a month: build the full platform, phased. Allowance reconciliation and lottery at pack and book level are the two items that are worth real money and are not for sale, and at this size the shadow spreadsheet has usually become a person's whole job.

Any operator actively acquiring: build, and treat the ability to absorb an unfamiliar register platform as a first class requirement rather than a later port. Every acquisition otherwise arrives with its own integration project and its own quarter of blind reporting.

Any operator whose problem is unread reports: change nothing until somebody owns reading them. That is not a brush off, it is the cheapest fix available to you.

If you want a second opinion before signing anything, Digital Heroes builds and runs its own products, so the people choosing your architecture live with those decisions on their own revenue. You can take that specification to any other firm on your shortlist.