Company name standardisation across registration and exhibitor systems

The exhibitor sales director wants one number. What did the Hartley group spend with us across the portfolio last year? Three systems hold part of the answer and none of them spell the customer the same way. The contract system has Hartley Instruments Ltd. Registration has HARTLEY INSTRUMENTS LIMITED, typed by a stand manager collecting badges. The CRM has Hartley Instruments (UK). Company name standardisation is the step that makes those three strings comparable, and it is a different job from deciding whether they are the same firm.

Teams usually skip straight to the second job. That is why the answer takes a week.

Why does one exhibitor arrive under six different names?

Pull the distinct company values for a single show from every system that holds them and sort by length. The variation has causes you can name, and each cause needs a different treatment.

Somebody typed it. A free text company box on a registration form collects whatever the attendee remembers, and people remember their employer's trading name, not the entity on the invoice.

The legal suffix moves around. Ltd, Limited, LTD., GmbH, S.p.A., LLC, Inc, Incorporated. The same company writes it differently on a contract than on a badge.

Somebody added a qualifier. Hartley Instruments (UK), Hartley Instruments Group, Hartley Instruments EMEA. Sometimes that qualifier is a real subsidiary and sometimes it is a person disambiguating for their own benefit.

The system truncated it. A field with a 40 character limit turns a long name into a different string, and the truncation point depends on which system did it.

Case and whitespace drifted. Double spaces, a trailing space from a paste, capitals from a scanner, an ampersand in one system and the word "and" in another.

Only the first three of those are interesting. The last two are mechanical and should never reach a human.

The pipeline, in the order it has to run

Order matters, because a later step can undo an earlier one. The sequence that holds up is this.

Trim leading and trailing whitespace, then collapse any run of internal whitespace to a single space. Uppercase the result. Remove punctuation that carries no meaning in a company name, which is full stops, commas and apostrophes, while keeping ampersands and hyphens for now. Strip the legal suffix using a published list. Collapse whitespace again, because removing a suffix leaves one behind.

Two of those choices deserve a moment. Ampersands are worth keeping through the first pass and then normalising deliberately, because a company that writes itself as Baker & Sons in one system and Baker and Sons in another needs one rule applied to both, and it matters which direction you go: converting the word to the symbol shortens the string and converting the symbol to the word makes it tokenise more sensibly for anything downstream that splits on spaces. Hyphens are the same argument in miniature. Pick a direction, write it in the specification, and apply it to every source on the way in rather than to one source after a complaint.

Write that output into a new column. Leave the original alone.

That last instruction is the one teams break, usually under time pressure during a migration, and it is the only one that cannot be recovered from. ISO 8000-110, first published in 2009 and revised in 2021, sets requirements for exchanging master data that can be checked by computer, and its title names the three things it covers: syntax, semantic encoding, and conformance to a data specification. The practical reading for an event business is that a standardised value only means something if the specification that produced it is written down and can be applied again. A column you overwrote in place has no specification anybody can apply, because the input is gone.

Where should the suffix list come from?

Most teams write their own suffix list. It has about twelve entries, all English, and it was written by whoever was closest to the problem on the day.

There is a published alternative. The Global Legal Entity Identifier Foundation maintains the Entity Legal Forms code list under ISO 20275, published in 2017, and describes the standard as specifying "the elements of an unambiguous scheme to identify the distinct entity legal forms in a jurisdiction". The current version, released in February 2026, lists more than 3,600 entity legal forms across more than 200 jurisdictions, and GLEIF publishes it free in Excel and CSV.

For a show with a German, Italian and Japanese exhibitor base, the difference between twelve hand-written suffixes and a list of that size is the difference between standardising the British exhibitors and standardising the floor. Load it once, keep the local abbreviations column, and treat your own additions as a documented extension rather than a replacement.

One warning. Strip suffixes only from the end of the string, and only as whole tokens. A blanket search and replace for "SA" inside strings will eat the middle of SANDVIK and the start of SAAB.

Case folding breaks in places you would not think to test

Uppercasing looks like the safe step. It is the one that behaves differently depending on where the code runs.

Two examples an event file will actually contain. The German sharp s, written as a single character, has historically uppercased to a sequence of two capital S characters, so a firm written one way in the contract system and the other way in registration will standardise to the same string, which is what you want, but only if both systems apply the same rule. Turkish makes the opposite trouble: the language distinguishes a dotted and a dotless i, and a case conversion that respects the Turkish locale maps a lowercase i to a capital I with a dot above, which no other locale produces. Run the same uppercase function on the same string on two machines with different locale settings and you get two different answers.

The fix is to pin the locale explicitly in the transformation, usually to the invariant or root locale, and to write down which one you pinned. It takes one line. Finding out later that half your Turkish exhibitors standardised differently in March than in November takes a week.

What the arithmetic looks like on a real file

Take one show, three systems, and count distinct company strings before and after.

Suppose the union of the contract system, the registration file and the CRM yields 4,812 distinct company strings. Run the pipeline above and count distinct standardised values: 4,190. The standardisation removed 622 distinct strings, or 12.9 per cent of them, and every one of those 622 was a pure formatting difference that would otherwise have needed a comparison decision.

That 12.9 per cent is the cheap part, and it is worth measuring separately from everything else, because it is the part with no judgement in it. Reporting it on its own stops the argument about whether the matching is working. If a further 318 of the remaining 4,190 differ only by a trailing qualifier such as GROUP or EMEA, that is a second, smaller number, and it needs a human decision about whether a divisional name is a separate customer for your commercial purposes. It usually is for the sales team and usually is not for the finance team, which is a business question rather than a data one.

Track the first number weekly and it becomes a regression test. If the distinct count after standardisation jumps by 200 overnight, something upstream changed, and that connects to the country and subdivision fields arriving from the same forms that K12 covers.

There is a second measurement worth taking at the same time, and it costs one more query. Count how many of your 4,190 standardised values appear in more than one source system. If the answer is 1,900, then 2,290 standardised names exist in exactly one place, and those are the ones your cross system reporting will never join no matter how good the matching gets, because there is nothing on the other side to join to. Splitting the file that way before anybody tunes a threshold saves a great deal of argument about match rates that were never achievable.

What standardisation cannot decide

Two firms can standardise to the same string and be different companies. SMITH ENGINEERING appears in a US registration file and a UK one, and they are unrelated. Standardisation has made them comparable and it has also made them identical, which is worse than where you started if the next step treats string equality as identity.

That next step, the scoring and the threshold that decides whether two comparable strings are one entity, belongs to cluster J and it needs more than the name: a country, a postcode, a domain from an email address. The handoff between the two stages should be explicit in your pipeline, with the standardised name as an input to matching rather than an answer.

The same separation applies downstream. A subdivision code stored with its country prefix, which K13 covers, is one of the fields that makes two identical company strings separable, so the geographic work and the company work pay each other back.

Where this stops

Standardisation improves comparability and it does nothing for a name that is wrong.

An attendee who types their client's name instead of their employer's produces a clean, well-formed, standardised string pointing at the wrong company. So does a stand manager who registers a colleague under the parent group. Neither is detectable from the string, and the only signals that catch it sit elsewhere in the record, usually the email domain, and sometimes not even there for the large share of registrations that arrive with a personal address.

There is a second limit worth stating to whoever asked for the number. Companies restructure. The Hartley group of 2023 may be two entities in 2026 and part of a larger group in 2027, and a standardised name has no opinion about which of those is true. A portfolio spend figure built purely on names is a snapshot of how the customer was written down, and it needs an entity identifier behind it before anyone takes it to a board, which is what the wider unified data record exists to hold.

Start this week by counting distinct company strings per source system for one show, running the trim, uppercase and suffix strip described above, and counting again. The gap between those two numbers, expressed as a percentage, tells you how much of your duplicate problem is formatting and how much is going to need a matching decision. It takes an afternoon and it changes what you ask for next.