Field note 29

Hold an ambiguous spreadsheet match instead of choosing a row

A paper source branches to two equally weighted red candidate slips, with neither selected. Conceptual illustration of an ambiguous supplier match.
Two matches. No chosen row.

MAJLS LABS

A supplier code can survive a spreadsheet transfer perfectly and still point to the wrong business. Before choosing a supplier row, collect the complete candidate set. One candidate goes to human review. Several candidates, no candidate, a blank key or contradictory identity evidence stay on hold.

This is the next question after preserving an identifier: not “did every character survive?” but “does this evidence identify one supplier?” It is narrower than reconciling competing field values. The useful output is a mapping-review packet, not a cleaned supplier master.

Why the first match is not a decision

Microsoft documents that XLOOKUP returns the item corresponding to the first match it finds.[1] That behavior is useful for retrieval, but a returned row does not show whether another matching row exists. A familiar supplier name or a different sort order must not settle an identity question.

Define the comparison rule before running it. Microsoft’s EXACT function is case-sensitive and ignores formatting differences.[2] Our rehearsal uses literal, case-sensitive string equality; every character, including a trailing space, matters. It does not trim, pad, change case or repair punctuation. We are specifying a review rule, not claiming to have run an Excel workbook.

Worked example: five source rows, seven possible candidates

Synthetic rehearsal. All suppliers, documents, people, codes and references below are fictional. These printed fixtures are the complete exercise, not customer data, a live export or verified supplier paperwork. Backticks enclose JSON-style strings: quote marks delimit the raw string and are not part of it. "" is empty; "SUP-27 " ends in one ordinary space. No other code contains hidden spaces.

Freeze source snapshot S-v1, candidate snapshot M-v1 and document fixture DOC-v1. Row references stay fixed after sorting. The candidate table is the entire search scope, including nonmatches and the placeholder. Identity references are separate from supplier codes.

Candidate ref Raw supplier code Fictional supplier Identity ref
M-v1:A "00184" Cedar Workshop Supplies VEN-C18
M-v1:B "SUP-27" Harbour Office Goods VEN-H27
M-v1:C "SUP-27" Meadow Packing Goods VEN-M27
M-v1:D "ALT-9" Birch Workshop Goods VEN-B09
M-v1:E "" Unassigned placeholder none
M-v1:F "sup-27" Willow Office Goods VEN-W27
M-v1:G "SUP-27 " Delta Packing Goods VEN-D27

The source table is also complete. The quoted document strings are the actual evidence within this fictional fixture only; their authenticity and business applicability are not established outside it.

Source ref Raw code Document evidence Full exact candidate set Disposition
S-v1:U "00184" DOC-v1:1: "Supplier identity: VEN-C18" {M-v1:A} Unique candidate; human review pending
S-v1:M "SUP-27" no identity document supplied {M-v1:B, M-v1:C} HOLD: multiple candidates
S-v1:N "SUP-99" DOC-v1:2: "Supplier identity: VEN-X99" {} HOLD: no candidate
S-v1:Z "" no identity document supplied {}; blank search deliberately excluded HOLD: blank key
S-v1:C "ALT-9" DOC-v1:3: "Supplier identity: VEN-C18" {M-v1:D} HOLD: conflicting identity evidence

For S-v1:M, case excludes M-v1:F; the trailing space excludes M-v1:G. Neither exclusion permits dropping M-v1:C, which exactly matches. For the blank source, the placeholder is not an identity candidate: matching absence to absence establishes nothing.

The last row is the important counterexample. Its code has one exact candidate, but that candidate identifies Birch while its document names Cedar’s identity reference. Cardinality alone cannot release it.

Decision guide: what each hold needs

In this fictional exercise, Omar Nabil, preparer, gathers evidence and lists candidates. Maya Faris, supplier-record owner, alone decides identity and approves an exact mapping proposal. Consequential approval remains with named human owner Maya Faris, never the assistant. These names grant no actual MAJLS authority.

Source Omar’s next evidence task Maya’s pending decision
U Confirm scope completeness and owner-recognized provenance for DOC-v1:1 and M-v1:A Approve or reject only S-v1:U → M-v1:A; agreement is not automatic approval
M Obtain source-linked identity paperwork and identity records for both candidates Select a specific mapping only if evidence distinguishes the suppliers; explain the excluded candidate
N Check whether the intended supplier belongs in this master scope Confirm wrong scope, missing master record or source error; no guessed substitute
Z Obtain the missing code or independent source-linked identity evidence Approve a separately documented correction/matching proposal; never treat the placeholder as the supplier
C Obtain provenance and applicability evidence for the source document and Birch record Resolve the contradiction explicitly; do not prefer the code or document merely by habit

None of these decisions has occurred. If evidence cannot distinguish identities, the hold stays open. A master-data correction is a separate task. Even an approved identity mapping is not permission to merge, import, pay or change a system.

Executable review checklist

Start with one troublesome row and print its full candidate set. The immediate action is not to improve a match score. It is to make the unresolved identity visible enough for the right person to decide.

Sources

  1. XLOOKUP function
  2. EXACT function

Discuss the process with MAJLS ↗