Why your DEFRA submission gets rejected, and how to fix it

A rejected submission is not a disaster. It is DEFRA telling you, at the door, that a field in the record does not match what the service expects. The record is not reported until it is accepted, so the fix matters, and nearly every rejection we see at a receiving site falls into one of five classes. This guide walks through each one and what to do about it.

One thing to know from the start: the error message usually points at the field but not at the format. Once you know the classes below, that is enough to find and fix the problem quickly.

What a rejection actually means

For permitted or licensed sites in England and Wales, every load received has to be reported within two working days. A rejection does not stop that clock: the record is not reported until it is accepted, so the correction and resend sit inside the same window. The load stays unsubmitted, and in most cases it is one field away from going through.

Rejection one: the authorisation number

The site permit or authorisation number is the field we see entered incorrectly most often. It has to be the number for the site receiving the waste, in a format DEFRA recognises, and a number it does not recognise is rejected with an error saying it "must be in a valid UK format".

These are the quick checks:

• The number must belong to your site. A carrier registration (CBDU123456) or your DEFRA API code never goes in this field.
• Where the format has forward slashes, keep them. A dash in their place, such as EPR-AB1234CD, is rejected even though the rest is right.
• Old licence numbers keep their prefix: WML43604, not 43604.
• Copy it exactly from your permit, or from the public register for your nation, rather than from memory.

Every nation's accepted formats, with examples, are in our permit number guide.

Rejection two: the carrier registration number

The carrier's registration number is part of the data required on every waste receipt submission, and an invalid number means the submission may be rejected. The number belongs to the business that carried the waste, and it typically takes the form of a prefix (CBDU for an upper tier registration, CBDL for lower tier) followed by digits.

When this one fails, it is usually because:

• the registration has lapsed, with the carrier still handing over the old number;
• the number does not match the business name recorded on the register; or
• the number belongs to the wrong party entirely, for example your own site's registration in the carrier field.

Every registration is checkable on the public registers, which show the registered business, the tier where one applies, and whether the registration is current. LoadLog runs that check as the note is created, and warns while the driver is still at the gate. More on how the register works, and what to do when a carrier is not registered, is in our carrier registration guide.

Rejection three: the spreadsheet route

If you use DEFRA's spreadsheet route, the data is not checked as you type: errors are found once the file goes through. If the service finds an error, it is recorded against the affected waste movement in the spreadsheet, and the correction goes back in within the same two working day window.

Two habits make that survivable. Submit early in the two working day window rather than on the last afternoon, so a bounce never becomes a missed window; and keep one organisation per file, as the guidance requires, so a problem in one organisation's rows does not hold up another's. The fuller picture of the spreadsheet route, costs and limits is in our spreadsheet guide.

Rejection four: codes, descriptions and weights

The waste code needs to match the material. An EWC code that describes something else than the description on the record, or a hazardous code where the load is not hazardous (the star after the code means hazardous), is the kind of mismatch that comes back. The same goes for fields left blank: a weight or a treatment code missing from the record is a submission waiting to be bounced.

If you are unsure which code fits a material, the EWC code lookup covers the catalogue, and our guide to EWC codes explains how to choose between the codes that look similar.

When the send fails instead

Not every bounce is about your data. Endpoints time out, and a submission can fail mid-send with nothing wrong in the record. Software connected to the API should retry on its own: with LoadLog, a failed send is retried automatically, and the note stays as an editable draft rather than disappearing.

The test is repetition. A record that fails once and goes through on the retry was an infrastructure hiccup. A record that fails every attempt is almost always one of the data classes above, so check the authorisation number, then the carrier number, then the waste code, in that order. Do not create a second copy of the load to push it through: fix the original, or you risk two records for one load.

What our submission data shows

We keep a close eye on this loop, because every LoadLog send goes through it. Across the three weeks to 8 October 2026, 38 production notes needed a second attempt. Between them, 75 sends failed, and 36 of the 38 notes went through on the retry or after a small correction.

The breakdown is more reassuring than those numbers first look. Most failed sends were never about the record at all: 35 were the DEFRA service timing out, and 21 more were connection settings that needed checking on the sender's side. The remaining 19 were record faults, and none of them were exotic: a receiver authorisation number or a postcode in a format the service would not take, seven of each, then smaller slips such as a carrier registration number that did not line up with the name on the register when the note went in.

The practical lesson mirrors the section above. Retry once before changing anything, because most failures clear by themselves. If it fails twice, it is one of the data classes, and with those in hand the correction is usually a minute's work.

Fixing it inside the window

The sequence that resolves most rejections:

1. Read the error for the field it names, then match it against the classes above.
2. Correct the record where it already is: a draft note, a spreadsheet row, or the template behind it. Do not retype the load from scratch.
3. Resend, and confirm the acceptance reference comes back.
4. If the same error repeats after an apparently correct fix, walk the other classes in order; the second-most-common cause is usually the one behind it.

LoadLog is built around this loop. Records are checked against the schema as they are entered, so the most common format problems are caught before submission rather than after it; sends that fail are retried; and anything a rejection holds back stays in your notes list as a draft you can correct and resend, with analysis to guide the fix. A rejected submission becomes a five minute job rather than a lost afternoon.

This article is our interpretation of the published guidance rather than legal advice, so where something matters for your site, check with DEFRA or your national environment agency.