By WasteSignal · England, Scotland and Wales
On this page
Choose digital waste tracking software by asking it to handle the receipts your business actually receives. A product may connect to the government service yet have limitations that affect particular movements. Staff also need to obtain the source information, understand submission results and correct mistakes after the initial upload.
This guide gives you practical questions for a supplier discussion and demonstration. It does not rank products or suggest that buying software guarantees compliance. Start with who needs digital waste tracking so that you are buying for an established role and activity. Our waste data and digital tracking guide explains the broader programme.
The current first phase concerns in-scope receivers, mandatory in England and Wales from 1 October 2026 and beginning in Scotland on 1 January 2027. The collector phase is planned for October 2027. Ask suppliers to distinguish available receipt-reporting functions from features they propose to add for a future phase.
Do I need to buy digital waste tracking software?
The government receipt service supports an official spreadsheet route as well as compatible software connected through its API. Establish whether your existing software can meet the current reporting requirements before buying another product. A reporting project may need a supported upgrade or configuration change rather than a complete replacement.
Review the full work involved with your current route. Include collecting information from the site, answering supplier queries and checking results. If manual entry is manageable and reliable, that may inform your immediate decision. If staff repeatedly retype large volumes or struggle to trace failures, those are specific problems to discuss with a provider.
The spreadsheet route is under review, so include future flexibility in your planning without treating a withdrawal date as settled. Ask whether your source data could be used with another reporting method later. Keep the underlying movement information in a usable form, regardless of which route currently sends it.
Read spreadsheet uploads before comparing the work involved. The purchase decision should consider your receipts and staffing, including cover during absence. Software that saves effort for a central administrator may still create extra work for the people recording arrivals if the information is poorly mapped.
What does API compatibility mean?
An API allows software systems to exchange data. In this context, the relevant connection is to the government’s Receipt of Waste API. A supplier’s ability to generate a report or export a spreadsheet does not necessarily mean it has that connection. Ask which actual submission route the proposed product uses. The official software-provider guidance explains compatibility and production approval tests. It says buyers remain responsible for ensuring the software meets their regulatory requirements. The published list is useful evidence of the stated compatibility; it is not a general government recommendation of a vendor’s service quality or suitability for your business.
Confirm the exact product, version and service included in the quotation.
A provider may sell several systems or offer the reporting connection as an additional module. Record what is available now and what depends on further work. A statement that a company appears on a list is less useful if it does not identify what you would actually receive.
Ask the supplier to explain any production approval test exemptions and their operational effect. Some products do not handle particular scenarios, including hazardous movements. Compare those limitations with your receipt arrangements and obtain a clear answer about anything outside scope. Do not assume that a general compatibility claim covers every waste stream you handle.
What should I prepare before speaking to suppliers?
Write a short description of your operation, identifying the legal organisations, facilities and countries involved. Include the reporting routes you already use and the systems holding your source information. The supplier should be able to understand who reports what without guessing from a group website or a list of trading names.
Describe ordinary receipt volumes and the unusual movements you genuinely handle. Include relevant complexities such as several waste codes, hazardous information or different administrative teams. Use representative examples with identifying information removed where appropriate. A demonstration based entirely on the simplest load may reveal little about the difficult part of your work.
List the problems you want solved and their consequences for staff. For example, the current system might not connect a successful reference back to the local ticket, leaving someone to reconcile it manually. Explain that problem precisely. A supplier can then show how its product handles it, and you can check the answer against your own process.
Use a short demonstration record to keep answers comparable:
| Question | Evidence to ask the supplier to show |
|---|---|
| Can staff follow a receipt through reporting? | Its source record, result and returned reference. |
| What happens to a rejected record? | The visible error and the action assigned to resolve it. |
| Does the product handle our specialist movements? | The relevant scenario and any stated limitations. |
| Can we retrieve our history? | A usable sample export with movement references. |
Agree which requirements are essential for launch and which would be useful later. Keep future collector plans separate from immediate receiver reporting. This helps prevent an attractive future feature from displacing a current need, such as making rejected submissions visible to the person who can resolve them.
How can I test whether software handles our waste information?
Use a demonstration based on realistic fictional receipts representing your operation. Ask the supplier to show where each value comes from and how the product checks it before sending. Include a deliberate missing value so you can see whether staff receive an understandable message and can locate the affected movement.
For quantities, examine units and whether the value is actual or estimated. For party details, ask how standing records are maintained and what happens when a contractor changes. A system may consistently send whatever was entered months ago; consistency alone cannot establish that the data still describes today’s receipt.
Where you handle specialist waste, involve the colleague who understands the classification and supporting information. Software should let staff record the applicable particulars accurately. It cannot replace the underlying assessment merely by offering a menu of waste codes. Our receipt information guide helps frame those questions.
Ask to trace one movement from its original site record to its reporting result. Note each manual step and any information that has to be supplied separately. If the demonstration leaves an unexplained gap, ask who would fill it in during normal operation. This gives you a more realistic picture of implementation than a summary showing only the final successful screen.
How should software display reporting results and errors?
Staff need to distinguish a local draft, a record waiting to send and a confirmed reporting result. Ask what each status means and how it is updated. The provider should explain which information comes from the government service and which is generated by the local product. Avoid relying on a colour without a clear meaning.
Test an initial rejection and an uncertain outcome during a demonstration. Can the user find the affected receipt and understand the next action? Ask how the software prevents an unresolved item from disappearing from the ordinary work list. A successful connection for one example does not demonstrate reliable handling of a failed attempt.
Explore corrections to a previously submitted record. Ask how the original reference is used, how changes are recorded and how staff confirm the result. If a standing-data mistake affects several movements, establish how those records would be identified. Read submission errors for the distinction between initial validation failures and later-discovered mistakes.
Make notification ownership explicit. Someone must see failures in time to act, including during absence. Ask whether alerts can reach the appropriate role without exposing unnecessary information to everyone in the organisation. Check the proposed arrangement with staff who will actually monitor it; a notification sent to an unmonitored mailbox adds little practical protection.
Can one product cover several sites and legal organisations?
Ask the supplier to demonstrate the structure your group needs. The government service can accommodate organisations and their sites, but your local configuration must preserve the correct relationships. A shared administration team should be able to tell which legal operator is associated with a receipt before it is submitted.
Test two similarly named facilities in the demonstration. Ask how the user identifies the intended site and what appears on its receipt record. Consider whether default values could put a movement against the wrong facility. A convenient default needs clear review where a colleague regularly switches between sites.
Discuss how access should differ for local staff and central administrators. A weighbridge operator may need to record arrivals while a central colleague investigates reporting errors. Define those tasks first and ask the provider how the product supports them. Keep account ownership and staff departure procedures clear so that access remains manageable when responsibilities change.
If an organisation or site changes, ask how its history is preserved and how future records use the correct relationship. Do not overwrite old identities merely to make the current screen tidy. The answer should let you distinguish what applied to a past receipt from what applies now, with a usable record of the change.
What support and outage arrangements should I ask about?
Ask who deals with service access, software faults and regulatory questions. Providers can explain their own product; your national regulator is the route for questions about your reporting obligations. Record those boundaries in the implementation plan so staff do not wait for the wrong helpdesk to answer an urgent question.
Examine support hours against your operation. If receipts arrive at weekends or outside the administration team’s hours, agree how problems are captured and escalated. Ask what information support needs, such as the affected local reference and a description of the error, so the reporting team can prepare a useful enquiry.
Discuss what happens if the connection is interrupted. Ask how the product records an uncertain result and what a user should do before repeating a submission. Establish how pending items will be reconciled after recovery. Avoid accepting a broad promise of automatic retries without understanding how staff can check the movements involved.
The applicable outage rules must still be followed. GOV.UK guidance and the English regulations describe the recovery period differently, so resolve uncertainty with the relevant regulator. Ask whether the software lets you capture the required information during an interruption, and how staff will distinguish that temporary record from a confirmed submission afterwards.
How should I compare prices and contract terms?
Ask for a quotation tied to your actual configuration. Identify whether charges relate to sites, users, movements or particular modules. Include setup, training and any work needed to connect an existing system. A low headline subscription can be difficult to assess if essential reporting functions sit in an unpriced option.
Keep commercial charges separate from the government service charge.
Ask who pays each charge and which organisation it concerns. If a provider offers to handle administration on your behalf, obtain a clear description of that service and the evidence you will receive. An invoice marked compliance does not explain the reporting tasks completed.
Read the support and change provisions with someone responsible for the operation. Ask what happens if the government interface changes, the product has a limitation or you need to add a facility. Record who is responsible for configuration and testing before a change reaches live reporting. Avoid relying on a verbal assurance that every future development is included.
For comparison, use the same questions with each supplier and record unanswered points. You do not need to assign a numerical score to every feature. A short note explaining that one product lacks an essential scenario may be more useful than a large total built from minor conveniences.
Will I be able to retrieve my waste data later?
Ask what you can export and whether the export includes the references and information needed to interpret it. Request an example using fictional records. A list of quantities alone may be insufficient if you later need to investigate a particular receipt or explain which source information supported it.
Discuss access to historical data if you change provider or close an account. Establish the available format, the process and any charges before signing. Keep those arrangements consistent with your organisation’s record-retention needs. Do not assume a software subscription automatically fulfils every retention obligation applying to movement documents or authorisation records.
Consider correction history and supporting material as well as the final values. If an export loses the relationship between a receipt and its later correction, someone reviewing the data may struggle to understand a discrepancy. Explain the practical investigations you need to support and ask the supplier to show how the exported information would help.
Data access should also be limited appropriately. Ask who can retrieve records and how access changes when a colleague leaves. Your internal policy should explain where exports are stored and who may use them. Keep real supplier and movement information out of public demonstrations or training files unless that use has been properly authorised.
How should I sign off the software before using it live?
Create an acceptance list from the essential scenarios discussed with the provider. Record what was demonstrated, any limitations and who will resolve outstanding work. Use the supplier’s testing environment as directed and keep fictional test records clearly separate from live reporting. Confirm how the live organisation and facility details will be checked.
Train the people who will report and those covering them. Ask each to find a receipt, explain its status and handle a sample problem. Update the local procedure where a step is unclear. The person signing off should understand any remaining manual work and ensure someone owns it.
After introduction, review a small sample of actual records against the source and submission result. Check whether staff can find unresolved items and whether information is reaching them on time. Use checking waste data quality and how to report receipt of waste to keep that review focused on the working process.