Methodology for standardizing names We have a great amount of data with user generated names for company names (think of bills where the company wrote their own name). In our data cleaning phase, we clustered the different companies together based on other values and we can assign a standart name to each cluster to solve a good chuck of the cases resulting in something like:
AMAZON:
Amazon
Amazon Website
Amazon online
Website Amazon
(non related company name)
Amazon UK
...

ZARA:
Zara
Zara S.A
(mall center name with a Zara in it)
(non related company name)
...

Now we need to filter out the cases that behave like the elements in the cluster but their actual name doesn't match the standarized name. Using a distance algorithm (Damerau-Levenshtein) gives mixed results at this point.
Is there a better methodology for this?
EDIT: I'll give a more specific example 
TOYS R US:

Toys r us <city name>
Toys r us <adresss>
Toys 'r' us
ToysRus
Toys & us
Toys 'R us
Tos R us
Target <city name>
Target
Simon mall

All the variations of toys r us are correct, tos r us would be a typo, Target would be incorrect. Simon Mall is one case I don't expect to resolve without manual supervision (it has a Toys r Us)
 A: I worked with almost identical-looking data when I wrote some very basic code for personal use, classifying expenditure by type based on the names appearing on my bank statements. I wonder if there's a "keep it simple" solution, exploiting the way brand names are consistently placed at the start of your strings while the potentially confusing store codes or locations come later - the same occurred in my data set. Matches at the start are more important: "TOYS R US WASHINGTON DC" should match "TOYS R US SEATTLE" despite a longer sub-string in common with "APPLE WASHINGTON DC".
First, I suggest you strip out spaces, punctuation, possibly digits (which often were for store or transaction codes in my data, rarely the company name) and switch to ALL CAPS. For initial classification it was best to work with truncated data since the ends of the strings seldom identified a company. The first 7 characters sufficed for me, which coincidentally is fine for "TOYSRUS". 
If an initial letter string (a) dominates a category and (b) appears in no other categories, its subsequent appearances can be fairly safely categorized without human intervention. Ditto if some records had previously been classified by hand, and all names with a particular initial string were placed in the same category. I encountered partial matches, as in your data when "Toys & Us XXX" would be processed to "TOYSUSX". I tried matching as many initial letters as possible: here we'd still have a four letter match with "TOYSRUS". If that is the best available match, the software would recommend it, but flag the record up for human inspection to confirm or override the category. You could do a more sophisticated distance calculation than just counting the number of corresponding initial letters, so that "TOYSRUS" would be identified as an even stronger candidate match for "TOYSUSX" (my algorithm would find it no stronger a match than "TOYSHOP"), but human confirmation is probably still desirable.
Some ambiguous situations arose: in my data set, records for grocery shopping at a store, a phone contract with that store, and withdrawals from a cashpoint at the store, all began with the store's name. I wanted to classify them separately. My software would detect the same initial 7 character string already appeared in records assigned to several different categories. It would then look deeper into the string - perhaps all prior instances matching on, say, 10 letters had been placed in the same category, so that one would be used. Basically, I had to look far enough into the string to see if "MOBILE" or "CASHPOINT" followed the store name. I can't see analogous cases in your sample data, but I imagine "SHOPPING PLAZA TOYS R US" needs distinguishing from "SHOPPING PLAZA APPLE".
If still unable to determine which category was correct, the software would flag up the record and present the user with a dropdown to select between the candidate categories (with an option for manually overriding and using a different category altogether if necessary). For unusual initial letter combinations with no near-matches, again it would flag up the record, but now present the user with a dropdown to choose from all possible categories.This happened every time I shopped at a new store.
This is only a rough sketch of the algorithm I used but gives the general idea. I actually used clues from other fields like transaction amount to make a plausible initial dropdown selection for the category if there was no good match on the name field (from past data, the software would suggest an unidentified expensive transaction on a weekend was likely "home furnishings" not "groceries", though accuracy here was unavoidably low) or flag up items that didn't seem to belong in the category their names suggested. Of course, other fields might be either more or less informative for you than they were for me. I considered adding a subprocedure to the code if letters 1 to 7 for a record did not give a good match: see whether letters 2 to 8 fared better, if not then try 3 to 9, and so on. For you, this would detect instances of "SHOPPING PLAZA TOYS R US" without resorting to other fields. But I never implemented this functionality, since for the data I generated, the name-matching code I'd written did an essentially perfect job once the pool of human-checked records had reached a fairly small size.
