When Mia Chen becomes Mia Patel in an export
A fictional rename case separates confirmed identity from a similar name and explains legacy matching, dated staff links and duplicate checks.
Two exported names can belong to one person. Two similar names can also belong to different people. Our fictional file contains both situations: Mia Chen and Mia Patel share source staff ID STAFF-17, while M. Patel has STAFF-42. A helpful matching tool must preserve that distinction rather than guess from spelling.
Worked fictional example · amounts in AUD
The useful part
Confirm a rename against independent source identity evidence. A dated workspace can keep one staff ID across names and aliases, but an alias is still a user assertion rather than proof of identity.
Your working files
Download the rename investigationCSV · Three fictional rows with names and independent source staff IDs.Three rows, two identities
N301 names Mia Chen and has a $100.00 excluding-tax basis. N302 names Mia Patel and has a $150.00 basis. Both carry STAFF-17 in an additional source column. N303 names M. Patel, carries STAFF-42 and has a $100.00 basis. All amounts and people are fictional, and the two confirmed Mia rows use a supplied 40% rate.
The source ID is evidence for this case, not a field the workspace automatically uses to link a person or select an agreement. Before accepting the rename, the fictional reviewer checks the source staff record and confirms that STAFF-17 remained the same person. Similar spelling alone would not provide that confirmation.
| Reference | Exported name | Source staff ID | Treatment |
|---|---|---|---|
| N301 | Mia Chen | STAFF-17 | Confirmed former name |
| N302 | Mia Patel | STAFF-17 | Confirmed current name |
| N303 | M. Patel | STAFF-42 | Separate identity; do not merge |
What the public matcher can establish
The staff-name matcher compares names after ignoring case and repeated whitespace. It can also use an alias you explicitly enter, such as “Mia Chen = Mia Patel”, when Mia Patel is in the supplied team list. It does not apply fuzzy matching or silently decide that M. Patel must be Mia Patel.
This gives the tool a narrow, useful job: show direct matches, matches based on your confirmed aliases and unmatched rows. The alias field records an assertion supplied by the user. It is not independent evidence that the assertion is true, and a successful match should not be represented as identity verification.
The calculation after identity confirmation
The confirmed STAFF-17 rows have bases of $100.00 and $150.00. At 40%, they produce $40.00 and $60.00, a combined $100.00. The STAFF-42 row remains outside that total until its own identity and rule are established. Adding it because the names look close would raise the total to $140.00 and misattribute $40.00.
This is why identity review belongs before a final statement is prepared. A correct percentage applied to the wrong person is still a wrong result. The arithmetic is easy; the evidence about whose sale it is determines whether that arithmetic belongs in a particular staff total.
Use a stable link after confirming the person
Older, unupgraded workspaces match flat rules by normalised staff name. An account owner can explicitly upgrade to a dated staff directory: the migration creates stable person IDs and agreements, then existing matching draft names are linked. A confirmed rename keeps the former display name as an alias; the source label stays unchanged. New imports can link an exact active name or alias, while an unknown or archived-name match needs a deliberate person link. The workspace does not infer identity from source staff IDs or transfer aliases entered in the public matcher.
For this mixed-name export, confirm STAFF-17 in the source before adding Mia Chen as an alias for Mia Patel or manually linking either row. Keep M. Patel separate because STAFF-42 is different evidence. Preserve the original file and the mapping explanation. A legacy workspace can still use documented separate rules or an explicit upgrade, but separate legacy rules may produce separate staff summaries and are not equivalent to one stable identity.
A rename can also affect overlap detection
The legacy exact fingerprint includes a normalised staff name alongside reference, date, item, category and amount. Trimsum preserves the original import identity when you correct a draft row. A run closed in dated mode also records a canonical staff-ID key, so the same sale linked to the same person remains a hard repeat after a rename. Against older runs without those IDs, a changed name can instead raise a similar-sale question that requires an explanation before inclusion. An exact previously finalised sale remains blocked.
A similar-sale warning is evidence to inspect, because legitimate split staff lines can share those fields. A changed reference, item or amount can still evade that narrower comparison. Compare the original item record against completed runs, and do not treat an absent warning as proof that a row is new. Keep a rename register stating the old name, new name, evidence and source-change date.
A useful refusal prevents a confident error
M. Patel remains unmatched in the supplied Mia-only team example because STAFF-42 identifies a different record. If the reviewer lacks enough evidence to establish who that person is, the correct next step is to inspect the source or ask the responsible person. Inventing an alias just to make the unmatched count reach zero would erase the problem.
The matcher also rejects conflicting alias claims and ambiguous team names after normalisation. Those checks protect the consistency of the supplied mapping, not its truth. A perfectly consistent mapping can still be wrong if the underlying confirmation was careless.
Leave enough evidence for the next export
Keep the three-row sample and compare it in the staff-name matcher. Enter Mia Patel as the team name and the confirmed Mia Chen alias. Expect N301 to match by alias, N302 directly and N303 to remain unmatched. The source staff-ID column remains visible in the downloaded source even though it is not used for automatic matching.
For a recurring process, the valuable output is a decision that can be revisited: which source identity changed, what evidence confirmed it, which periods contain both names and how overlap was checked. The dated directory preserves an approved link and alias for future imports, but it does not independently verify that the two exported names belong to one person.
Put it to work.
Inspect source rows, supplied rates and review decisions in the sample workspace.
Explore the sample close