ERP with an integrated point of sale
Running a business end to end — inventory, purchasing, accounts and people in one dataset, sized for a single outlet or a company with several, with the till as part of the system rather than a separate one that has to be reconciled afterwards.
- Warehouse asks
- What is physically here? 420.
- Sales asks
- What can I promise today? 240.
- Purchasing asks
- What will I have on Thursday? 570.
What we would build
Stock is a number three systems disagree about
Sales says an item is available, the warehouse says it is reserved, and accounts say it was already invoiced. All three are reading a different question as though it were the same one. Getting an ERP right starts with deciding that on-hand, reserved, in-transit and committed are separate quantities, and never letting a screen add them together.
The ledger cannot be edited, so nothing else can either
Accounting entries are corrected by a reversing entry, never by an update. Once that is true of the ledger it has to be true of everything that posts to it — a shipment that quietly changes after invoicing puts the books out by exactly the amount nobody can find. Most of the discipline in an ERP is this one rule, applied consistently upstream.
Pricing is rules, not a number on a row
A price depends on the customer, the quantity, the unit of measure, the contract and the date, and every business has an exception that breaks whichever model you picked. The workable answer is to evaluate price as a resolved rule and store the result alongside the inputs, so an invoice from eighteen months ago can still explain itself.
Documents that must reconcile in threes
A purchase order, a goods receipt and a supplier invoice describe one event and rarely match. Partial deliveries, short shipments and price differences are the normal case, not the exception. Three-way matching is the feature that decides whether finance trusts the system, and it is far cheaper to design in than to bolt on.
Multi-outlet, without a second source of truth
The moment there are two locations, transfers, local stock and a consolidated view all have to be answerable from one dataset. Businesses that grew into a spreadsheet per branch have already learned what happens otherwise, which is usually why they are talking to us.
Point of sale that keeps working offline
A counter cannot stop selling because a connection dropped. That makes the till a system that queues and reconciles rather than a thin client, and it forces an early decision about what it is allowed to do while blind — which prices it trusts, and what it must refuse.
What this usually replaces
- A stock spreadsheet one person maintains
- A second stock figure, in the accounting package
- Prices agreed by phone and remembered, not recorded
- Purchase orders living in an email folder
- A till reconciled against sales at close of day
- Month-end spent finding where the two numbers diverged
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.