Your POS closed the day at a profit. The stock count the next morning says you are short on the items you actually sold most of. Nobody can say which number is right, so the shop does what it did last year: close the register, count the shelf, and argue about the variance.

Where the gap comes from

Two systems cut off at different times. Your POS closes at 11pm, the stock report runs at 6am, and the delivery that landed at 9:30pm is on one side and not the other.

Units do not match either. The counter sells a piece, the godown counts a dozen, the bakery counts in kilos. Returns come back through the billing counter and never reach the stock screen. Discounts and GST live in one system but not the other, so sales value and stock value get compared as if they meant the same thing. Damaged stock gets written off by whoever found it, on a different day, in a different column. And purchases get entered as a note under the register instead of a receipt against the item — each of these is harmless alone, and together they produce a variance nobody can explain.

Decide what you need before you decide what to build

There are three levels here, and most businesses only need the first one.

A daily report that pulls sales and stock into one view. Nothing writes back to either system. The POS keeps selling, the stock system keeps counting, and you get one screen that says what sold, what moved and what the variance looks like.

One-way sync. Sales come out of the POS and deduct from stock on their own, so the count reflects the floor without anyone re-keying it. This is where most of the work sits.

Two-way sync. Purchase receipts and returns go back into the POS, so the number on the screen is the number the billing counter sees. This one is expensive, because the POS now has to accept data it was never built to accept.

What has to be true before anyone promises an integration

This is the part worth arguing about on the call, and it starts with the question that decides most of the scope: does your POS expose an API, or only a CSV export? Exports are workable. A nightly file that nobody has to open by hand is enough for a lot of these reports — a report that has to be typed out again is not.

Do you have stable item codes? If the same product has three spellings across the counter, the outlet and the godown, nothing reconciles until somebody fixes that. Software will not fix it for you.

Who owns each field? Stock, price, customer, supplier. Pick one owner per field and write it down. When two systems both think they own the price, you have built a place where arguments happen instead of data, and that is where the real cost hides.

How far back does the data go, and how clean is it? A dashboard over two years of hand-entered purchase rows is a different job from one over six months of clean exports. We ask this early because it moves the quote more than anything else in the brief.

And what happens when the export breaks, or the vendor changes their plan and the API goes away? Anything we build needs a manual path behind it. If the only route is the API, then the day it stops working is the day the numbers stop arriving.

The report is the deliverable

Ask an owner what they want and they will say a dashboard. Watch which screen they open first and you get the real answer.

For a restaurant group it is usually outlet-wise sales against food cost, with the variance called out on the items where the theoretical and actual numbers have drifted apart. For a distributor it is stock by warehouse against sales by sales-rep, with credit outstanding sitting next to it. For a bakery or a small processing unit it is batch consumption and wastage against production.

Those are different screens on the same plumbing. Getting the plumbing right and letting the owner define the view on top of it costs less than building one screen per question.

What we build, and what we will not promise

We scope this as a piece of work: discovery first, a clear statement of what your data actually allows, then the build.

We will not promise that a specific vendor integration works until we have checked the access you really have, and we will not commit a timeline before we have seen the data. A clean API and a messy CSV are two very different projects, and pretending otherwise is how quotes go wrong.

What you get is the working build, the documentation, and a handover your next developer can pick up.

When you do not need any of this

Some businesses should leave the POS alone.

If you sell twenty items a day from one counter, one person owns the numbers and the variance is small enough to spot by eye, then the integration will cost more than the problem. Count the shelf, close the register, move on.

The moment to look at it is when two people need the same number at the same time, or the weekly report eats an afternoon of manual work, or a purchase arrives and nobody can say whether it was added. That is when the gap between two systems turns into a cost you can measure.

Most of this work is unglamorous: a data model, a scheduled job, a screen that loads fast on 4G, and a written answer to which system wins when they disagree.

Related: workflow automation and custom business software cover how we scope this kind of work, admin dashboards covers the reporting layer, and real builds shows what has shipped. If the variance report is eating your Monday, bring the sheet.