Validate the whole supplied reference before accepting the request

Finding a valid-looking reference inside a message is different from establishing that the supplied field is a valid reference. A receiving application can confuse those operations even when the public form appears to validate correctly.

This fictional example concerns a finance-preparation request for a Singapore service business. It does not issue an invoice or move money. The organisation's rule requires an exact internal purchase reference before this request can enter the finance-preparation queue.

State the field's actual contract

For this particular system, the reference consists of the uppercase letters PO- followed by exactly four ASCII digits. PO-4821 is one possible value. The rule is fictional and internal; it is not a Singapore government identifier format or an InvoiceNow requirement.

The receiving service must also establish that the reference exists, belongs to the permitted customer context and is eligible for the requested action. Passing the format check alone does not satisfy any of those later questions.

The public form uses a whole-field pattern consistent with the agreed grammar. In its normal route, xPO-4821y is reported as invalid. An integration client, however, sends that exact larger string directly to the same receiving application. The receiver marks its format check as passed and creates a draft queue entry with the larger value.

Staff cannot reconcile the entry as an exact purchase reference. The input was not lost in transport and the customer did not submit PO-4821. The complete supplied value was xPO-4821y.

Locate the first incorrect decision

The inspected Python receiver calls re.search with the expression PO-[0-9]{4}. The search finds the substring PO-4821 inside the larger string. The routine treats the existence of that match as proof that the entire field meets the contract.

The Python regular-expression documentation distinguishes searching within a string from matching the entire string. re.fullmatch expresses the latter operation. The receiver's choice of operation, rather than a different spelling of the purchase code, explains the false acceptance.

This investigation does not solve the problem by extracting the matching substring. That would silently replace the supplied evidence with a different value. A prefixed or suffixed string might be a note, an error or a genuinely different identifier; the application has no authority to decide which.

Correct the receiving requirement

The chosen repair uses a whole-string match for the exact accepted grammar. It does not trim whitespace, discard a line ending, remove a prefix or extract a code from a longer comment. If the organisation later wants to accept a different input convention, that is an explicit rule change with its own review.

The receiver rejects an invalid field before creating the finance-preparation entry. The response identifies the field that requires correction and preserves the user's other permitted input. It does not claim an invoice was prepared or invite a repeat payment.

The browser check remains useful feedback, but the receiver enforces its own contract. The integration client and any other supported entry path must encounter the same receiving requirement. A screenshot of a browser error is not evidence that the backend already does this.

Complete a deliberate correction

In the private fictional exercise, request F-61 supplies xPO-4821y and receives a correction response. No new preparation entry is created. The operator consults the approved source and deliberately supplies PO-4821 through a new corrected attempt F-62.

That value passes the whole-field format check. Separate checks establish that the reference exists in this fixture, belongs to the authorised customer and can enter preparation. The receiver creates preparation record P-62 with exactly PO-4821 and the unchanged permitted job reference. Its state is awaiting the finance team's ordinary review.

The earlier incorrectly created draft is handled separately by an authorised operator: it is marked invalid for preparation, with its original supplied text and correction history retained. The repair does not silently relabel that historical entry as though it had always contained the approved reference.

Challenge the boundary with inputs that look almost right

The acceptance set includes a prefix, a suffix and a final line terminator. It also checks a leading space, a trailing space and a non-ASCII digit. All remain invalid under the stated exact grammar. Replacing a full match with a loosely anchored expression must not reopen a final-newline exception.

Two independent valid references, PO-4821 and PO-4822, keep their own identities. An empty field requests correction. A well-formed but unknown PO-9999 passes only the format question and then fails the separate existence check. A permitted-looking reference belonging to another customer fails the authority check.

These controls prevent the repair from turning into a broad “accept anything that contains four digits” rule or an assumption that a correctly shaped identifier grants access. They also establish that the operator's corrected attempt produces one preparation record in the described exercise, without making an idempotency claim about every future retry.

Keep financial decisions outside this format test

A valid reference is evidence about one field. Finance still determines the approved document, accounting treatment and readiness for the selected provider workflow. InvoiceNow-related requirements and provider permissions are separate dependencies; this example establishes none of them.

The handover should retain the grammar, exact receiving operation, invalid-input examples and later existence and authority checks. Use invoice workflow development for the complete finance handover, or API integration when several clients supply the same receiving process.