How to ensure Remit scans are sent to customer's Data Manager from the Pitney Bowes Hub using Mail360 Data Manager

Product Affected: EngageOne Delviery Audit/Mail360 Data Manager
FYI- Remit Codes are on mail pieces that are being sent *back* to a mailer, such as with bill payments enclosed.  The Remit code allows the mailer to track the payment mail piece on it's way to the mailer.

A customer informed the USPS, and PBS, that they would be using 9-byte Remit Codes on their mail pieces, such as 123456789.  But actually they were putting 11-byte Remit Codes on the mail pieces, such as 12345678989

According to the USPS, if a mailer registers a 9-byte Remit Codes with them, but is actually putting 11-byte Remit Codes on the mail pieces, then the scans *will still be sent* to the PB Hub as long as no other mailer has registered any 11-digit Remit Codes starting with the same 9 digits.
Or just to say it another way- if the mailer's registered 9-byte Remit Code is unique, in that it’s the only registered Remit Code that starts with those 9-digits, then the last 2 digits of an 11-byte remit code on a mail piece do not matter.  The scan data will be sent to the PB Hub.  
The Remit Codes in question were unique in the first 9 bytes, so the USPS was sending the Remit scan data to the PBS Hub.

*But* the Hub contains a table of exactly what remit codes are to be routed to which customer's Data Manager.  If the Hub is setup to forward a 9-byte Remit Code like 123456789 to a certain customer, but the customer puts an 11-byte Code on the mail pieces, it does not match, and the Remit scan data will *not* be sent to the Data Manager.  It will instead be moved into an 'unprocessed' folder on the Hub and remain there.

Also, the USPS said that although the 11-byte Remit Codes would be sent to the PBS Hub in certain cases as discussed above, it might be a good idea for the mailer to actually register the correct 11-byte Remit Code with the USPS.
UPDATED:  October 4, 2017