Payment matching

Zuora's Smart Match AI uses a combination of OCR, pattern recognition, and historical learning to identify the correct customer and invoice for each payment. However, because scanned documents, handwritten data, and bank details can vary widely, some practical limitations apply.

Lockbox

Lockbox files usually contain a cheque image and invoice information — either keyed-in by the bank or embedded as a scanned image. Zuora's ML engine reads these inputs to identify the right customer and invoices.

Extracting the information

Zuora uses optical character recognition (OCR) to read visible information from each image. The process extracts invoice numbers, payer names, and amounts. Image clarity and resolution affect accuracy.

• Blurry or low-resolution scans can lead to missed invoice numbers.

• Handwritten cheques work best when handwriting is legible and consistently formatted.If it's easy for a human to read, it's easy for Zuora's OCR to interpret.

Match lockbox payments to customers

Zuora evaluates the following identifiers in order of reliability:

1. Match the invoice number.

   • Invoice numbers on scanned images serve as the primary key to locate the customer.

   • The ML model recognizes common patterns such as "INV-1234", but can misinterpret shortened or partial formats.

     • "INV-1234, 35, 36" → Correctly expands to INV-1234, INV-1235, INV-1236.

     • "INV123" vs "INV-123" → May not match unless the pattern was part of prior training.

   • Over time, the model learns new formats from manual corrections, but highlighting expected invoice patterns during setup helps reduce early-stage errors.To reduce errors, share expected invoice formats with your implementation team during onboarding.

   • Challenges with Scanned Invoices:

     • In some lockbox files, invoice numbers are printed within scanned invoice attachments rather than in typed overlays.

     • ML may fail to identify these if:

       1. The font is stylized or faint.

       2. The image contains handwritten or stamped content.

       3. The invoice number is positioned inconsistently across documents.

     • Consistent and high-quality invoice templates improve recognition reliability.

2. Match the bank account (MICR) information.

   • If the invoice number is missing or unreadable, Zuora attempts to match by bank account number using the MICR line.

   • The MICR line includes:

     • Routing number

     • Bank account number

     • Cheque number

   • This works primarily for U.S. accounts, as MICR formats vary by country.

   • Accuracy depends on the cheque number's position — incorrect placement can cause mis-identification.

   • Once a payment is confirmed and posted, the ML learns and associates that MICR pattern with the correct customer for future predictions. If the same bank account pays invoices for multiple customers (e.g., vendor or group payments), Zuora does not rely solely on bank account matching.

3. Using the Customer Name.

   If invoice and bank data are unavailable, Zuora reads the payer name from the cheque image and attempts to match it against your customer master.

   • Exact or close matches are supported; abbreviations are not.

     • "GlobalPay Solutions Limited" → Matches "GlobalPay".

     • "GPS Ltd." → Not matched automatically to "GlobalPay Solutions".

   • Near-match risk:

     • "Global Aviation Corporation" could potentially match with "Aviation Solutions", "Freight Aviation Solutions", or "Global Solutions", depending on overlap and prior learning.

     • When such ambiguous names appear, Zuora flags them for manual review instead of making an automatic match.

   • Alias or alternative names::

     • You can set an Alias for a customer that would enable Zuora's ML to look at alternative names for the same customer.

     • Example: "Batmobile Enterprises" can be an alternative for "Wayne Automobiles". You can set "Batmobile Enterprises" as an alias.

Bank statement

When Zuora processes a bank statement, it reads and extracts key payment-related fields from the file (e.g., BAI2, MT940, or CSV). These fields are then used for matching payments with the correct customer, invoice, and posting details in your ERP.Bank statement fields

Payment description example

Below is an anonymized example of a payment description as it might appear in a BAI2 or MT940 statement:

0925B6U2R018594 2800960 0269593 BANK OF XYZ, N.A., NY 222 MAIN STREET NEW YORK, USBANK OF XYZ, N.A., NY 222 MAIN STREET 9201192236447OGB=AlphaCorp DISBURSEMENT 4500 CENTRAL BLVD SUITE 200 DALLAS TX 75201ORG=AlphaCorp Inc 4500 CENTRAL BLVD, SUITE 200 DALLAS TX 75201 USRFB=9201192247 OBI=/ROC/9201192447 OPI=58009201 /FTR/BNF=4064683 1/OMEGA TECH SOLUTIONS 3/US/NOTPROVIDED,NOTPROVIDEDBBI=/LOCINS/CTRC

This description includes details such as the originating bank, payer name, transaction identifiers, and beneficiary details. Zuora uses this information — particularly the payer name (e.g., AlphaCorp) and reference numbers (e.g., RFB, OBI, TRN) — to match the payment to the correct customer and transaction.

Customer matching

Zuora's ML model analyzes the Payment Description text to identify the likely customer. The same matching logic and limitations apply as with Lockbox payments:

• Exact or near-exact name matches work best.

• Abbreviations or name fragments are not auto-matched.

• For ambiguous matches (e.g., "Global Aviation" vs. "Freight Aviation Solutions"), the closest match is set as the customer.

• You can set an Alias for a customer that would enable Zuora's ML to look at alternative names for the same customer.