ASK ADAM: Old COA – NCOALink Issue

Why are there no clues on the piece and yellow label to indicate why a match could not be made and a new address provided by NCOA^Link®?

QUESTION
There are no clues/indicators on the piece and a yellow label to indicate why a match could not be made, and a new address provided by NCOA^Link®. The address on the piece is fully valid, the new address is fully valid, and the name of the yellow label or in the ACS™ record is the same. Why didn’t NCOA^Link® make a match – especially with an older COA where the record was most likely processed several times via NCOA^Link®?

APPROACH
NCOA^Link® has some limitations. There are scenarios where, even though a match was made and the new, domestic address is known and valid – NCOA^Link® is not able to return the new address. But, it does return a Footnote result code to indicate when this occurs (and the reason). So, check the NCOA^Link® Footnote codes for this record
There can be a number of reasons that may only impact a small number of records, thus helping it go undetected. The first thing to check is if the name and address information is getting correctly pulled and submitted to the NCOA^Link® processing. Truncated or missing information can prevent matching.

POSSIBLE ROOT CAUSE/SOLUTIONS
The address information is in 2 address lines, with the secondary data (APT #) being in the second line. But, only the first line is sent to NCOA^Link®. This will prevent matching for some of the records with secondary address data. Mis-pulled or mis-identified fields. Is the full name and address data being correctly pulled in identified correctly in the processing job.

EXAMPLES
Example: The first character of the name is not getting used. This will prevent matches to pretty much all records filed as an Individual COA. But, matches would still be made to Family COAs. You can look at the NCOA^Link® Processing Summary report to see the matching rate at the Individual Level vs. the Family Level. FYI – NCOA^Link® always tries to match at an Individual Level before a Family Level.

Example: It is surprising how many businesses use their business name as their address (“101 MARKET ST LLC”). This is fine, until they move. If the data holds both a Name and Business Name, but the processing job only has 1 name field, the Business Name is typically placed in an Address field – typically, the Address 1 field, which is the Primary Address Line. When CASS looks to code an address, it starts with the information in the Primary Address line. If that codes, that is what is used. So, in this case, the address codes to “101 MARKET ST”). Yes, there is a COA for that address – but it is under the Business Name, not the individuals name.

Example: In the example, the piece was processed in May 2025, the COA was from Nov 2024, the COA was detected by automated processes (not carrier identified), the COA was for the whole family (so, only needed to match on the new name), the last name on the piece matches the last name on the yellow label, and there is no issue with the new address.

So, why was a match not made and a new address obtained from NCOA^Link® processing? In this specific case – there was an additional twist, the new address on the yellow label was the same address that was on the piece. This is due to a very, very weird situation evolving both a LACS^Link® change and a COA that should not have been filed.

The resident was made aware of the pending LACS change. They, mistakenly, thought they needed to file a COA from the old format address to the new format. They filed, and that COA went into the system. Then the LACS change went into effect. So, in the build of the COA data, the old format address was updated to reflect the LACS change – resulting in a COA where the old and new address were the same address.