Don’t commission bespoke EPOS software until you know which gap you’re paying to close. If the manager just needs yesterday’s takings by payment type, first ask the till supplier to demonstrate its existing report. If another system can import that report unchanged once a day, try the file import. A custom integration is worth scoping when those options leave a specific, recurring job undone.
Give the developer one awkward trading day
Suppose a venue manager copies cash and card movements from the till into a weekly operations report. The report is used for running the venue, not for calculating tax. Here’s an invented, deliberately small export with one refund against a sale from yesterday:
| Till event | Payment type | Movement |
|---|---|---|
| S101: counter sale | Cash | £24.00 |
| S102: table payment | Card | £48.00 |
| R103: refund of yesterday’s S099 | Card | −£12.00 |
For a report defined by the day the money moved, today should show cash £24, card £36 and total £60. That is not £60 of new orders: there were £72 of new payments and a £12 refund. A report grouped by the original sale date answers a different question. Get the manager and developer to agree which figure belongs on screen before either starts building.
Test the parts a happy-path demo skips
- Same file twice: import those three events a second time. The total must stay £60, not £120. Ask which identifier distinguishes a repeat from a genuine second sale. If two tills can both issue receipt 101, the receipt number alone isn’t enough.
- Late refund: first deliver only S101 and S102. The screen should show £72. Deliver R103 later and expect £60, with a way for the manager to see what changed.
- Missing file: withhold the next day’s export. The manager should see “not received” and the last successful import time. A zero-sales day is a different result.
- Close after midnight: if your Friday shift ends on Saturday morning, supply one example from either side of midnight. Write down which trading day each belongs to and check that both systems agree.
These are acceptance tests: the person signing off the work can run them and say yes or no. They’re not promises that your till exposes every field. If the source only supplies daily totals, don’t quote for receipt-level reporting until someone has confirmed access to the underlying events.
A brief you can copy
Our duty manager spends ___ minutes per shift moving ___ from [till/report] to [destination]. The destination needs to be correct by ___. It groups by [trading day/calendar day] and treats refunds as ___. We have attached a made-up or anonymised sample and our expected result. If a file is missing, ___ should be notified. The person who will check and sign off the result is ___.
For a first conversation, use invented receipt references and strip out names, contact details and payment credentials. Ask for a fixed first milestone: one venue, one destination, one agreed report. The quote should distinguish the initial build from ongoing costs, including any supplier charges for data access and who investigates a failed import.
When is it worth doing?
Time the existing task for a week. For example, 12 minutes per shift across 25 shifts is five hours per month. Compare the value of that time and any avoidable errors with the build and support costs. If the export takes ten minutes once a month, a documented manual process may be the better answer.
For the till-side checks, see how to reconcile an EPOS close-out. If the handover is the part that needs building, see Codeer’s custom software service. Bespoke work is scoped separately from the standard till.