Lockbox overview

A Lockbox is a banking service where customers send their payments (typically cheques) to a secure mailing address managed by the bank. The bank deposits the cheques and provides Zuora with digital copies of the remittance information, usually in the form of TIFF or PDF images. The following details are expected to be read from the corresponding Lockbox data file.

1. Check number

2. Payer name

3. Invoice reference or memo

4. Amount paid

5. Deposit date

Lockbox data may arrive as either keyed-in or non-keyed-in (scanned) formats. Both are image-based, but differ in how remittance data appears on the image and how the Optical Character Recognition (OCR) engine interprets them.

Keyed-in lockbox

In a keyed-in lockbox, the bank's operations team manually types key remittance details (like invoice numbers and payer names) directly onto the scanned cheque or remittance image.

You will notice the data as typed overlays (for example, machine-printed text) on the cheque image or on an additional page. This method improves OCR accuracy since the details are clearer and follow standardized positioning.

What to expect in a keyed-in lockbox file:

1. File Type (Image Format): .tiff (or) .pdf

2. Typed Information (Overlay text keyed in by the bank): "INV-12345 – $1,200 – Bob Inc."

3. Check Image (Visual scan of the cheque): Embedded in TIFF/PDF

4. Invoice Details (Typed remittance information): One or multiple invoice numbers

5. Deposit Info (Deposit date, lockbox number, and batch ID): Lockbox 4058564683 – 06 Oct 2025

How is it used?

• The OCR engine extracts both the overlaid typed text and visible cheque fields.

• Invoice IDs, payer names, and amounts are parsed directly.

• Payments are created and linked to invoices based on the extracted data.

Non-keyed-in (scanned) lockbox

A non-keyed-in lockbox contains only the scanned cheque and remittance stub, that is, no manually typed overlays. Here, the remittance section is purely visual, that is, handwritten or printed as part of the original stub.

Zuora's OCR engine reads invoice numbers, payer names, and payment amounts directly from these images.

1. File Type (Image Format): .tiff (or) .pdf

2. Typed Information (Not typed in, Scanned image): No information is typed in.

3. Check Image (Original Cheque): Embedded in TIFF/PDF

4. Invoice Details (Scanned Image of attached document): The entire invoice along with the sender envelope can be found as a part of the above file.

5. Deposit Info (Deposit date, lockbox number, and batch ID): Lockbox 4058564683 – 06 Oct 2025

How is it used?

• The OCR engine identifies invoice-like patterns (INV-xxxx), numeric values, and payer strings.

• The extracted data is sent through Smart Match AI to suggest likely invoices or customers.

• Any unreadable or ambiguous image is flagged for manual review under Exceptions.

Bank files: Understanding BAI2 format

Zuora also supports structured BAI2 (Bank Administration Institute 2) files, a standard electronic statement format used by banks to share transaction data for ACH or wire.

A BAI2 file is structured with record codes, each representing a specific type of information. Zuora reads and interprets these codes to identify payment details, amounts, and references.

What to expect in a BAI2 file

• 01 – File HeaderIdentifies the sender, receiver, and file creation date.

• 02 – Group HeaderGroups transactions belonging to the same bank or reporting entity.

• 03 – Account IdentifierSpecifies the bank account number, currency, and account-level details.

• 16 – Transaction DetailContains the main transaction information — transaction type, amount, and reference number.

• 88 – Continuation RecordIncludes additional memo or descriptive text such as payer information or remittance references.

• 49, 98, 99 – Trailer RecordsRepresent account-level, group-level, and file-level totals respectively, providing control and reconciliation data.

Example: ACH / Wire Credit Transaction (BAI2 format)

03,4058564683,,015,1200000,,/
16,195,500000,V,250502,,9876543210,T123456789/
88,FR:FT INCOMING - SWIFT
88,ENDT:20250502
88,TRID:T123456789
88,PY:PAY273517 DV+-25676-FEB-25-7122
88,BI:1234567
88,BN:ABC GLOBAL LTD
88,BN1:123 MAIN STREET
88,BN2:NEW YORK
88,OB1:XYZ SOLUTIONS LLC
88,OA:USD500000
88,BO:CUST987654
88,BO1:XYZ SOLUTIONS LLC
88,BO2:456 MARKET STREET
88,BO3:SAN FRANCISCO
88,BO4:94107,US

What Zuora extracts from this record

This record represents a credit transaction (incoming payment); likely through ACH or Wire transfer.

1. Transaction Data Extracted

   • Transaction Code: 195 → Incoming Credit (ACH/Wire).

   • Transaction Type: FT INCOMING - SWIFT.

   • Value Date: 2025-05-02.

   • Amount Received: 500,000.00.

   • Currency: USD.

   • Receiving Account: 9876543210.

   • Transaction ID: T123456789.

   • Payment Reference: PAY273517 DV+-25676-FEB-25-7122.

2. Payer / Originator Information

   • Payer Name: XYZ SOLUTIONS LLC.

   • Payer Address: 456 Market Street, San Francisco, 94107, US.

3. Beneficiary (Receiving Entity)

   • Beneficiary Name: ABC GLOBAL LTD.

   • Beneficiary Address: 123 Main Street, New York.

Skipping Non-AR Transactions

Bank statements typically contain a mix of transaction types, including:

1. Credit transactions

2. Debit transactions

3. Summary or balance entries

4. Other non-relevant records

Not all of these qualify as Accounts Receivable (AR) transactions. To ensure accurate processing, the system filters out irrelevant transactions using the methods below.

Default behavior

By default, the system processes only credit transactions, as these represent incoming customer payments. All other transaction types are ignored unless explicitly configured.

Filtering mechanisms

1. Receiving Bank Account Number

In some cases, a bank statement may include transactions across multiple bank accounts. If you want the system to process transactions only from specific bank accounts, you can configure a bank account filter. Only transactions associated with the selected account(s) will be considered

Note: This configuration is currently provisioned via the support team.

2. Payment Codes

Bank statements include payment (transaction) codes that indicate the nature of each transaction (e.g., customer payment, bank charge, transfer). These codes are critical for identifying valid AR transactions. Only whitelisted payment codes are processed. All other codes are ignored. This helps eliminate non-customer transactions such as:

• Bank fees

• Internal transfers

• Adjustments or reversals

Payment codes must be configured based on the bank statement format being used. Each format has its own set of transaction codes. Relevant codes should be identified and whitelisted during onboarding. The system supports:

1. BAI2

2. BAI3

3. MT940

Key considerations

• Filtering improves accuracy by ensuring only valid customer payments are processed

• Incorrect or incomplete configuration may result in missed or misclassified transactions

• It is recommended to validate payment codes during initial setup