A person finishes a public-service application a few minutes before a deadline. The upload bar completes, the button turns green, and the browser shows “submitted”. Then the page disappears. No email arrives. When the office opens, the record cannot be found.
The immediate problem is not interface polish. It is evidence. The person needs to show what crossed the boundary into government control, when it crossed, and what the authority promised to do next. A public-service receipt should therefore be treated as proof of submission, not as a courtesy message.
The gap between send and received
On paper, a clerk can date-stamp a copy while the applicant watches. Online, several systems sit between the submit button and the case file: the browser, an upload service, a gateway, a document store and the department’s case-management system. A success screen can appear after the first of those systems responds, even if a later transfer fails. An email can be delayed, filtered as spam or sent to a mistyped address.
The important design decision is where “received” becomes true. For a consequential application, the receipt should be created only after the service has durably stored the submission and assigned an identifier that staff can retrieve. If the service has merely placed data in a queue, it should say so: “upload complete; acceptance pending” is a different state from “application received”.
This distinction is easy to blur because a confirmation page feels final. The GOV.UK Design System says a confirmation page should include a reference number where one exists, explain what happens next and when, provide contact details, and let the user save a record of the transaction. Those elements are useful because they connect the visible page to an operational record. The colour of the panel does not.
What a useful receipt proves
A receipt needs an authoritative timestamp, including the time zone, and a stable reference number. It should identify the service and channel, show the fields that were submitted, and record the files received by name, type and size. It should distinguish the submission time from later administrative steps such as validation, eligibility checking or payment reconciliation.
That last distinction prevents the receipt from making a claim the authority has not yet earned. “Received before the deadline” may be appropriate if the service controls the official clock and has accepted the payload. “Your application is valid” is a legal or administrative conclusion that may require human review. The receipt proves the transaction state; it does not pre-judge the case.
Time evidence also has degrees. Under the EU’s eIDAS Regulation, a qualified electronic timestamp carries a presumption about the accuracy of its date and time and the integrity of the bound data. An ordinary service confirmation is not automatically such a timestamp. Authorities should use stronger trust services where the legal risk warrants them, while making clear what an ordinary receipt does and does not establish.
The person should be able to retrieve the receipt later without being forced to create a full account for a one-off interaction. Government guidance recommends avoiding accounts when a usable service can be provided without them and suggests a unique reference for checking a one-off transaction. A downloadable copy, a safely designed retrieval link or a reference combined with limited verification may be enough.
Show the record without spreading it
A complete receipt can itself become a privacy hazard. Copying a benefits form, health attachment or domestic-violence disclosure into an unencrypted email creates a second, poorly controlled record. The Information Commissioner’s Office explains data minimisation as holding the minimum personal data needed for the purpose.
That principle should shape the receipt. A screen or protected download can reproduce the submitted answers when doing so helps the person check the record. An email may need only the service name, timestamp, reference and a route back. Sensitive values can be partly redacted; attachments can be represented by filename and file properties rather than copied. The service must still retain enough evidence to settle a dispute about what arrived.
Before submission, a separate review step should let people inspect and change their answers. The GOV.UK “check answers” pattern places that review immediately before the final action. After submission, the receipt freezes the accepted version. If a person discovers an error, the receipt should point to a correction route and preserve version history rather than silently rewriting the original.
Duplicates are evidence, too
Missing feedback encourages people to press submit again. A weak service may create two cases, charge twice or discard the second attempt without explanation. A stronger service gives each attempted submission an idempotency key: retries carrying the same key resolve to the same accepted transaction. The person sees one reference, while the audit trail records the retries.
Not every repeat is accidental. Someone may intentionally send a corrected application. The interface must therefore distinguish “try again because confirmation failed” from “submit a new version”. When a duplicate is detected, the service should say which record it matched and what the person can do if that conclusion is wrong.
Email cannot be the only evidence channel. Official guidance notes that email confirmation can be delayed, sent to spam, or exclude people who cannot complete a blocking loop. A receipt should appear in the service first and be saveable there; email or text can provide a second path. If neither confirmation nor retrieval works, a human support route needs access to the same submission log, not merely the front-office inbox.
The strongest objection: a receipt can promise too much
Building durable receipts costs more than displaying a success page. It requires reliable storage, consistent identifiers across systems, careful retention rules, support tooling and reconciliation when components disagree. A detailed receipt may also confuse users or expose information on a shared device. And if its language is careless, people may mistake technical delivery for legal acceptance.
Those are reasons to define the receipt precisely, not to omit it. A compact first view can state the reference, time, current status and next action, with a protected copy of the submitted data available separately. The service can name the acceptance layer: “files received”, “application recorded” or “payment confirmed”. Complexity should remain in the machinery, while the promise shown to the person stays narrow and truthful.
The authority must own the boundary
No technical design can decide every contested case. Clocks drift, uploads can be corrupted, a deadline may have an exception, and a person may possess credible evidence that the service failed. The human boundary is responsibility: an accountable official must be able to accept evidence, correct the record and explain the consequence. “The system has no entry” cannot be the end of the inquiry.
A good service therefore tests more than whether receipts are sent. It checks whether people can retrieve them, whether staff can locate the underlying submission, how often duplicate attempts occur, how missing confirmations are resolved, and whether correction requests preserve deadlines. The decisive question is institutional: when the official receipt fails, what other evidence will the authority recognise, and who has the power to put the record right?
If you value practical analysis of human-centred public technology, subscribe to Alkemata for the next article in this GovTech series.