The 5 Stages of Manual Data Entry Before a CDS Declaration (and How to Remove Them)

For most UK freight forwarders, submitting a declaration to the Customs Declaration Service (CDS) is not the hard part. The hard part is everything that happens before the operator opens the declaration software.

Manual data entry in the pre-declaration workflow is where clearance capacity disappears. It is where keying errors are introduced, where backlogs form at peaks, and where experienced customs staff spend hours on work that does not require their expertise.

In 2025, HMRC recorded more than 91 million cleared declarations from 4,880 declarants. Volumes rose 7.9% while the number of declarants fell 13.7%. UK customs operations are processing more declarations through fewer declarants, increasing the need to handle higher volumes without a corresponding increase in manual preparation work.

This article maps the specific stages where manual entry occurs before a CDS declaration, explains what each one costs operationally, and sets out how AI-driven automation can remove manual work without changing the submission workflow an experienced operator already controls.

The challenge is not simply extracting information from customs documents. It is turning inconsistent paperwork into a complete, validated and traceable customs-ready entry within the software a forwarder already uses. That requires document processing, approved customs rules, integration and exception handling to work together, while experienced customs staff retain control over compliance decisions and submission.

The key distinction: automation in this context covers document reading, data extraction, validation and logic application. Experienced customs staff review, approve and submit the declaration to CDS. That is the right division of labour, and it is where the efficiency gains are largest.

Why pre-declaration data entry is the real bottleneck

Once the data is ready, creating and sending the declaration can be quick, although acceptance and release depend on CDS processing and any applicable controls. The data preparation that precedes it can take anywhere from 30 minutes to two hours per invoice, depending on document complexity and entry size.

For a forwarder handling 140 declarations a day, each with its own invoice to prepare, that can represent up to 1,400 hours of weekly preparation work before a declaration is submitted.

That figure is not theoretical. At Pentagon Freight Services, Ripple automated the preparation of approximately 140 UK customs declarations per day. At up to two hours of preparation per declaration, across five working days, that represented up to 1,400 hours of manual preparation work each week.

Ripple now prepares entries for review through Pentagon's existing Sequoia and CargoWise workflow, while Pentagon's customs team checks and submits them.

The bottleneck has three structural causes.

Documents arrive in formats that resist standardisation

Commercial invoices, packing lists, clearance instructions and purchase orders reach customs teams by email, in whatever format the shipper or importer uses. That means PDFs with merged cells, multi-page Excel files, scanned documents with inconsistent column structures and multi-document packs combining several file types in a single email.

No two customers send paperwork in exactly the same way, and the volume of variation makes manual standardisation impractical at scale.

Rekeying into declaration software is still largely manual

In operations without effective integration, once a document has been read, line data is typed or pasted into tools such as ASM Sequoia or CargoWise, field by field.

Each line requires the operator to transfer values from the source document into the correct data elements in the declaration system. On a straightforward single-line entry, this is manageable. On a multi-hundred-line commercial invoice and packing list, it is where errors accumulate and where the most time is lost.

Customs logic must be applied consistently across every line

Commodity codes, procedure codes and additional procedure codes, commonly referred to as CPCs, country of origin, licence and document references, and additional information codes may be supplied by the customer, derived from previous movements or supplemented by the operator.

In all cases, they must be checked against the requirements of the current shipment, and not every combination of codes is valid. Applying that logic correctly and consistently across high volumes, without a centralised system enforcing it, is a significant source of declaration errors.

A customs pack can also contain conflicting instructions. An invoice may carry a procedure code from an earlier movement while the accompanying email specifies the treatment required for the current shipment. Preparation therefore includes reconciling sources, and the agreed process must define which instructions take precedence, preserve their origin and refer unresolved conflicts to the customs specialist.

The cost of getting it wrong: Errors can lead to CDS validation failures, rejected declarations and delayed goods release. Where a pre-lodged import declaration is rejected on arrival, HMRC requires a corrected replacement declaration rather than an amendment. If the rejected declaration is linked to a goods movement reference, that GMR is held and cannot be linked to the replacement declaration. The goods must then follow HMRC's process for manual arrival and release, with the exact route depending on the location and declaration status.

Read HMRC's guidance on rejected pre-lodged import declarations.

The five stages where manual entry occurs

Manual data entry is not a single task. It is a sequence of distinct stages, each with its own error surface and time cost. Understanding where each one sits makes it possible to target automation precisely.

Stage 1: Document triage and sorting

Before any data is extracted, someone has to identify what has arrived, whether the pack is complete and which documents relate to which shipment.

For a busy clearance team processing dozens of email threads simultaneously, this triage is itself time-consuming. Missing documents may only be identified after the operator has already started working on the entry, creating rework loops before data entry has even begun.

What this costs: Operator time spent on inbox management rather than customs work. Incomplete packs that are only identified mid-process, delaying the entry and prompting a customer query.

Stage 2: Document reading and data extraction

The operator reads each document and identifies the values needed for the declaration: descriptions, quantities, values, weights, origin, consignee and consignor details, plus any licence or permit references.

On a well-formatted single-page invoice, this is straightforward. On a multi-page commercial invoice and packing list with hundreds of line items, inconsistent column headings and merged cells, it requires sustained attention and is highly susceptible to misreading.

What this costs: Time proportional to document complexity. Error rates that increase with entry size. Senior staff deployed on data reading rather than compliance judgement.

Stage 3: Rekeying into declaration software

Extracted values are typed or pasted into the declaration system, line by line. This is the stage most commonly associated with manual data entry, and it is where keying errors are most likely to occur: transposed digits in values, incorrect quantities, wrong units of measure or values entered into the wrong field.

What this costs: Direct error introduction into the declaration. Time that scales linearly with entry size. No systematic check that what was typed matches what was in the source document.

Stage 4: Customs logic application

With line data in the system, the operator applies or validates customs-specific elements that may be missing from, or outdated in, the source documents: commodity codes, CPCs, preference claims, licence codes and additional information codes.

This is the stage that requires genuine customs expertise. It is also the stage most affected by inconsistency, because the logic may be held in an operator's head or in per-customer notes rather than in a centralised, enforceable system.

What this costs: Declaration errors driven by inconsistent logic application. Dependency on individual operators who hold institutional knowledge. Vulnerability when staff change or volumes spike.

Stage 5: Pre-submission checking

Before the declaration is submitted to CDS, an experienced operator reviews the entry for errors. In a manual workflow, this check has to compensate for everything that could have gone wrong in stages one through four.

The more manual the earlier stages, the more burden falls on this final check and the more likely it is that errors still reach CDS.

What this costs: Checking time that grows with entry complexity and error rate. A false sense of security when checks are rushed under volume pressure. Rejections that consume far more time than the original preparation.

The five stages at a glance

• Document triage: main risk is incomplete packs identified too late; main time driver is inbox volume and email complexity.
• Document reading: main risk is misread values or missed lines; main time driver is document format and entry size.
• Rekeying: main risk is values entered into the wrong field; main time driver is line count per entry.
• Logic application: main risk is inconsistent codes and procedures; main time driver is operator knowledge and customer variety.
• Pre-submission checking: main risk is errors reaching CDS; main time driver is errors accumulated earlier in the workflow.

How automation addresses each stage

The five-stage breakdown shows that manual entry is not one problem. Each stage has a distinct failure mode, and effective automation addresses them separately rather than applying a single extraction tool across the whole workflow.

Replacing document triage with inbox-connected processing

Rather than an operator monitoring an inbox and sorting documents by hand, an AI system connects directly to the mailbox where customers send paperwork. It identifies what has arrived, classifies documents by type, associates them with the correct shipment and flags immediately if the pack is incomplete.

Missing documents surface at the point of arrival, not after an operator has spent time working on an incomplete entry.

This matters particularly for forwarders handling large numbers of customers simultaneously. The system processes documents as they arrive, including outside normal working hours, reducing queues caused by manual document handling.

Replacing manual reading with structured extraction

AI document extraction reads commercial invoices, packing lists and clearance instructions across a wide range of formats, including PDFs, spreadsheets and scanned documents, without requiring a template to be built for each customer's layout.

It pulls out line data, quantities, values, weights, origin and party details, then structures them for use in the declaration system.

The critical difference from template-based extraction tools is that this approach generalises across a wide range of document formats, including formats the system has not been specifically trained on. New customer formats can often be supported without building a new extraction template, subject to appropriate validation and configuration.

Line reconciliation is part of this stage. The same goods often appear on both the commercial invoice and the packing list. The preparation process must reconcile those documents without counting items twice.

Where goods lines can legitimately be consolidated, the system must apply the relevant CDS completion rules and, for simplified procedures, HMRC's aggregation rules. It should check compatibility across commodity codes, customs procedures, origin, preference, duty treatment and supporting documentation.

A matching commodity code alone is insufficient. The original line-level information and a clear audit trail must be retained.

Eliminating rekeying by writing directly to declaration software

Extracted data is written directly into the declaration system, creating the job and entry without an operator transferring values by hand. For a forwarder using ASM Sequoia, for example, the entry is created in Sequoia-ready format from the source documents, with no intermediate rekeying step.

This removes a primary source of keying errors and significantly reduces the relationship between entry size and processing time.

Some declaration information also exists in the forwarding system before document processing begins. The shipment record may already contain the job reference and validated party details. Automation should reuse that data, add the missing line information and flag discrepancies for review.

This makes the quality of customer master data part of the implementation scope, not an afterthought.

Centralising customs logic so it applies consistently

Customs rules and customer-specific requirements are managed through a centralised logic layer, not by individual operators drawing on their own knowledge.

Approved rules are applied consistently to the relevant shipments, with checks for commodity classification, procedure eligibility, origin, licences and supporting documents. Changes can be tested, approved and deployed centrally, reducing reliance on individual operator knowledge or multiple customer-specific spreadsheets.

This is the structural fix for inconsistency. Logic that lives in an operator's head or in per-customer spreadsheets cannot be audited, tested or enforced at scale. Centralised logic can be.

Reducing pre-submission checking to genuine exceptions

When stages one through four are automated, the pre-submission check changes in character. The operator is no longer compensating for accumulated manual errors. They are reviewing an AI-prepared entry that has already been validated against the source documents, with genuine exceptions flagged and routed to them with the issue already identified.

Standard entries flow to the operator ready to check and submit. Exceptions, such as ambiguous goods descriptions, missing licence references or unclear origin evidence, are flagged specifically so the operator's attention goes where it is actually needed.

For a practical guide to evaluating the software that handles this workflow, see How to Use AI for UK Customs Clearance.

For detail on how CDS validation changes are affecting pre-lodged declarations, see How to Reduce Clearance Rework Under CDS.

What the operator's role looks like after automation

A common concern when evaluating customs automation is whether it displaces the customs specialist. In practice, automation changes what the specialist does, not whether they are needed.

In a manual workflow, an experienced customs operator spends much of their time on tasks that do not require their expertise: reading documents, rekeying data and chasing missing information. Their compliance knowledge is applied in a narrow window at the end of the process, often under time pressure and on top of accumulated fatigue from earlier data work.

After automation, the same operator's day looks different:

• Document processing: Routine inbox triage is automated, with exceptions passed to operators.
• Data extraction and entry: The AI handles extraction and entry, so the operator does not rekey line data.
• Customs logic: Rules are applied centrally using controls the operator helped define. The operator does not apply codes from memory on every line.
• Exception handling: The operator receives flagged entries with the specific issue identified and applies expertise to the cases that actually need it.
• Pre-submission check: The operator reviews an AI-prepared entry and submits to CDS. They retain control over what is submitted.

The result is that the same operator can handle more declarations per day, with their attention concentrated on compliance decisions rather than data tasks. For forwarders absorbing growing declaration volumes without proportionally growing headcount, this is the practical mechanism by which capacity scales.

The human in the loop is not a workaround. It is a deliberate control. Automation prepares and validates declaration data, while authorised customs staff review the result, resolve exceptions and approve submission through the existing customs software. The responsibilities of the importer, exporter and customs representative remain governed by the applicable customs debt and representation rules.

The template problem: why some automation tools create new manual work

Not all customs automation removes manual entry. Some tools replace one form of it with another.

Some template-dependent extraction tools work by building a bespoke workflow for each customer's document format. The tool learns the layout of a specific customer's invoice and, once trained, can extract data from that format reliably.

The problem is what happens next.

A forwarder with 50 regular customers may need 50 templates, often more when the same customer uses different document formats for imports and exports. Each template requires a build cycle before it can go live. When a customer changes their invoice format, the template needs updating. When a new customer is onboarded, a new template may need to be built before their documents can be processed.

Where that is the case, the practical consequences are significant:

• New customer onboarding is delayed until the template build cycle is complete, which can take days or weeks depending on the vendor's process.
• Logic changes propagate slowly. A change to a commodity code or CPC that applies across multiple customers may require updates across each affected template.
• Template maintenance becomes an ongoing overhead, requiring a resource to manage the workflow library and keep it current.
• A single error in a template can apply to every document processed through it, multiplying the impact of what would otherwise be an isolated mistake.

The alternative is automation that applies customs logic centrally across customers without per-customer extraction templates. New customers can be onboarded without a template build cycle. Logic changes can be tested, approved and deployed centrally.

Template-free extraction does not mean rule-free processing. Approved customer rules, structured validation, exception handling and production monitoring still apply.

For forwarders evaluating automation tools, this is one of the most operationally important questions to ask: does the system require a separate workflow for each customer, and if so, who maintains it?

Where to start

Automating pre-declaration data entry does not require replacing the entire customs workflow at once. The most effective approach is to start with a defined scope, prove the results and expand from there.

A practical starting point for most forwarders:

1. Identify your highest-volume entry type. Import entries for a single high-volume customer, or a specific commodity type, give you a controlled environment to validate extraction accuracy and logic application before rolling out more broadly.
2. Map the current time cost per declaration. Track how long each stage takes today, from inbox to entry creation, and distinguish hands-on operator time from elapsed processing time. A declaration may sit in preparation while the system processes documents, even though the operator is free to progress another case. The baseline should capture document preparation, corrections, final review and time spent waiting, so the team can see where capacity is actually released.
3. Test on your worst documents, not your best. The documents that cause the most problems in a manual workflow are the ones that matter most in an automation evaluation. Bring your most complex commercial invoice and packing list packs, plus your most inconsistently formatted invoices, to any vendor demonstration.
4. Confirm the integration before anything else. Automation that does not write directly into your declaration software, whether ASM Sequoia, CargoWise or another system, has not removed the rekeying step. It has only moved it. Confirm exactly which systems the tool writes to in live production, not in a roadmap. A representative document pack should arrive in the receiving system against the correct job, with expected header information, complete invoice rows and any approved consolidation applied. The operator should be able to inspect the result and resolve flagged gaps. A successful extraction or generated XML file is an intermediate milestone. Acceptance means an accepted, usable record within the target system.
5. Expand by customer or entry type, not all at once. Once the first scope is working, the centralised logic model means adding the next customer or entry type is a configuration task, not a new build cycle.

The goal is not to automate everything immediately. It is to remove the manual stages that consume the most time and introduce the most errors, while keeping the operator's established workflow for checking and submitting to CDS.

Frequently asked questions

Can AI submit a CDS declaration?

AI can prepare, validate and route customs data into the declaration workflow. Experienced customs staff should review, approve and submit the final declaration through their existing customs software.

What causes manual customs data-entry errors?

Common causes include incomplete document packs, inconsistent invoice formats, duplicate lines across invoices and packing lists, incorrect units or values, outdated procedure codes, and missing origin or licence information.

Can customs automation work with ASM Sequoia or CargoWise?

It should work within the systems your team already uses. A proper integration should create a usable record against the correct job, including the expected header information, invoice rows and approved consolidation, with exceptions available for operator review.

What should freight forwarders test in a customs-automation pilot?

Test the workflow using real, difficult document packs. Include multi-line invoices, inconsistent customer formats, missing fields, duplicate lines, supporting-document requirements and shipments that need controlled consolidation.

The acceptance test should confirm a usable record inside the target system, not only a successful extraction or XML output.

See how Ripple handles customs data preparation

If your team is spending hours preparing declarations that should take minutes, talk to Ripple to see how it handles your documents, customers and declaration workflow.