Why planning submission changes slowly, until it doesn’t

Reviewed by a planning professional with 15+ years’ experience
Based on published Local Planning Authority requirements where relevant
Designed for architects, architectural technologists and planning consultants

Most digital services improve because users can leave. Switching creates pressure. Pressure tends to improve clarity, reliability and service standards.

Planning submission has never worked like that. It sits inside a statutory process, with formal requirements, public law duties and a high perceived cost of error. That changes the shape of improvement. Change tends to come more slowly, and usually through governance, policy, procurement and operational reform rather than through straightforward consumer switching alone.

That does not mean improvement is impossible. It means improvement usually arrives only when the administrative cost of the existing workflow becomes too visible to ignore.

The invalidation paradox

Invalidation is the clearest sign that the workflow still relies too heavily on downstream checking.

A valid planning application depends on more than sending a form. In England, Planning Practice Guidance is clear that a valid application requires a completed application form, compliance with national information requirements, the correct fee, and provision of local information requirements. The same guidance also makes clear that local planning authorities should publish and maintain local lists, and that those lists must be justified and kept under review.

That is why friction persists even when the formal application route looks standardised. Authorities publish forms, publish local requirements and publish guidance, yet applications still arrive with missing supporting material, certificate issues, plan inconsistencies or gaps against the local checklist. Welsh Government guidance similarly sets out structured lists of validation requirements for different application types, while council-level validation checklists in England make clear that applications may not be registered where relevant information is missing.

The structural issue is not that requirements exist. It is that many workflows still treat validation as something that happens only after an application has been received, rather than something that should be supported before submission.

A better workflow reverses that logic. It identifies common omissions earlier, tests the submission against published authority requirements before handoff, and makes the pack easier to register and assess.

The benefit is not convenience for its own sake. It is fewer invalidation loops, less avoidable rework and better control at the point where the application enters the authority’s process.

The real cost sits inside practice time

The largest cost in planning submission is often not platform cost. It is professional time.

It appears in small pieces:

• reissuing drawings
• renaming and re-uploading files
• correcting certificate errors
• rechecking local requirements
• chasing confirmations
• explaining delays to clients
• coordinating missing items with third parties

Because that cost is spread across practices, consultants, applicants and authorities, it often remains invisible at system level. It becomes background process noise.

That is one reason slow improvement has been tolerated for so long. The burden is real, but it is fragmented.

That tolerance is becoming harder to sustain. Fee pressure, tighter internal resourcing and stronger client expectations make repeated administrative rework more visible than it once was.

Why change happens in waves

Statutory systems often remain stable for long periods, then shift more quickly once several pressures align.

That is beginning to happen in planning submission now.

One pressure is operational. Practices are less willing to absorb repeat admin as an unexamined cost of doing business.

Another is digital. Government-backed work on planning application data specifications is explicitly aimed at reducing duplication, confusion, effort and inconsistency across local authority systems. That matters because it shows the problem is now being treated as one of structure and data quality, not just user behaviour.

A third pressure is institutional. Government funding has already been directed at improving the digital services councils use for the submission and assessment of planning applications, with the stated aim of improving software, enabling better data exchange and reducing friction in the planning process.

None of that guarantees a perfect solution. But it does show that the conditions for change are no longer weak. They are active, visible and increasingly difficult to defer.

Frequently asked questions

Is planning submission actually behind, or just complex?

It is complex. But complexity does not require repetitive avoidable admin. A regulated process can still be structured to catch predictable omissions earlier.

Why do local validation checklists cause so much friction?

Because they vary by authority and are often discovered too late in the submission process. The issue is usually not that authorities publish requirements. It is that practices often have to interpret those requirements under time pressure and across different local contexts.

Will better submission tools reduce LPA workload?

They can help if they reduce invalidations, make inputs more consistent and remove some of the avoidable checking that currently happens at intake. That is a reasonable inference from current government work on planning application data standards and digital planning improvement.

Can planning applications only be submitted one way?

No. Government guidance encourages electronic submission through the local planning authority’s website, and also provides for paper forms through the authority. The practical question is less about one exclusive route and more about whether the submission process is reliable and aligned with the authority’s published requirements.

What is the most practical way to reduce submission delay today?

Use a controlled document standard, check the relevant local validation requirements early, and review the pack as a submission set rather than as separate files at the end.