An unknown customer is a fact the billing process must preserve

A report with an empty customer field can create pressure to supply an answer quickly. The service event may be complete, the reporting period may be closing and other records may suggest a likely allocation. Yet a plausible answer is not necessarily an authorised financial fact. Sometimes the most accurate statement the organisation can make is that the customer relationship remains unresolved. The process should preserve that fact until the relevant evidence has been examined.

At Relzavi Clinical Linen Services we reviewed 320 processing bags and found twenty-seven without dependable customer identifiers. Their processing events were recorded. The uncertainty concerned which customer should receive the financial allocation. The distinction was important because a completed event did not supply the missing evidence by itself, and nearby activity did not necessarily establish the relationship we needed for billing.

The commercial team proposed using provisional allocations to close the period, with adjustments if a customer later queried them. Finance wanted the supporting evidence resolved before the allocation entered billing. I supported finance. We held the twenty-seven allocations for review and funded ₹41 lakh of record and handoff work. That decision accepted a delay in completing the affected billing allocations rather than treat a fully populated report as the objective that mattered most.

## Separate the event from its proposed financial use

A single operational record can support several decisions, each with different evidence requirements. The fact that a bag has a processing history may be enough for one operational question and insufficient for a customer charge. A data process should identify the proposed use before deciding whether the record is complete for that purpose. Otherwise, a broad label such as 'complete' can carry more authority than the underlying checks justify.

In our case, the missing identifier needed an accountable route to resolution. The data team could show the gap and assemble the relevant records. It could not simply nominate a customer because one seemed likely. Finance had to accept the allocation after the evidence was reviewed with the relevant teams. That was not an administrative obstacle added after the technical work. It was part of establishing that the record could responsibly be used for the financial decision.

The alternative proposal deserved consideration because closing periods and resolving exceptions both consume time. A provisional entry can sometimes be part of an authorised accounting process, depending on the circumstances and appropriate judgement. I do not claim that every uncertain record must be handled identically. In this specific case, the proposed customer allocations lacked the dependable identifiers required by the responsible finance owner, and the decision was to resolve that evidence before billing.

The distinction should remain visible to managers reviewing progress. A bag could appear in the processing account while its billing allocation remained on hold. That is not contradictory reporting if the two accounts answer different questions. It becomes confusing only when the organisation insists that every process must share one undifferentiated completion status. A more useful design explains what has happened and what use of the record is still awaiting approval.

There is also a practical issue in how the unknown state is presented. An unlabelled blank can be overlooked or filled by somebody who assumes it was an omission. A clearly identified unresolved allocation, with an owner and next step, communicates a different meaning. The system should help colleagues distinguish uncertainty from a missing keystroke. That design choice protects the decision while making the work of resolution easier to manage.

The ₹41 lakh programme addressed records and handoffs as well as the identified cases. A field can fail because its meaning is unclear, its source is unreliable or responsibility changes between activities. Asking colleagues to enter more data does not necessarily solve any of those problems. The review needs to understand how the identifier is established and what happens when it cannot be confirmed. Otherwise, the company may produce a higher completion rate without improving the evidence behind the entries.

## Resolution needs more than a populated field

Finance accepted the resolved allocations after the known cases were reviewed. That was the outcome for the twenty-seven identified bags within the 320-bag population. I did not describe it as proof that every allocation across the business was correct. Nor did I infer a customer outcome or a wider financial benefit beyond the records examined. The useful claim was that the specific uncertainty had been addressed through an accountable process before the proposed use proceeded.

The resolution should leave enough of a record for a later reviewer to understand what happened. Which evidence supported the customer allocation? Who accepted it? Was the underlying event changed, or only the relationship used for billing? Those questions can matter if a customer queries the account or if a similar exception appears again. A clean final table is not a substitute for an understandable decision history.

I also want the organisation to learn from the exceptions without treating every one as proof that the same cause applies. Several bags may lack identifiers for different reasons. Grouping them under one error code can help manage the queue, but the response may still need to distinguish a collection problem from a transfer problem or a disputed relationship. The analysis should preserve those differences where they affect the corrective work.

For directors, the broader question is how management handles uncertainty before it becomes money. A board need not determine the customer for each bag. It can ask whether the company recognises the gap, assigns authority and resists pressure to substitute plausibility for evidence. It can also ask how delays are accounted for so that the control does not depend on an invisible burden carried by one team at period end.

This case made my own definition of data completeness more specific. A record is complete for a stated purpose under an understood set of checks. It is not complete in the abstract merely because every field contains something. The distinction can sound technical until a number appears on a customer's bill. Then the question is straightforward: what entitled the company to make that allocation? A sound process should be able to answer without reconstructing the reasoning after the charge has already been made.

The unknown customer field was uncomfortable, but it told the truth about the evidence available at that point. Preserving it allowed the right owner to resolve the question. Filling it with a convenient assumption would have made the report look finished while moving uncertainty into the financial relationship. I would rather make the unfinished decision visible than let the appearance of a completed table decide what the organisation claims to know.