Skip to main content
Documentation
Documentation
Administrator Guide
Last Updated: 2026-09-18
Automated Bank Statement Line Processing

Automated Bank Statement Line Processing

Automated bank statement line processing converts the bank statement line data in incoming bank statements and maps them to customer payments and deposits by leveraging payment rule sets, remittance advice types, and customer mapping tables. Bank statement lines can generate multiple remittance advice lines on a payment when matched.

Conversion Execution

  • Data Extraction
    : Customer payment rules copy parsed segments of bank statement line fields into structured remittance advice types, such as Invoice Number, Customer Name, Other.
  • Field Concatenation
    : The background process concatenates these populated remittance advice fields into a single combined string before executing an exact-match lookup against the mapping lookup table.
  • Lookup
    :
    • During execution, the job scans all populated remittance advice fields on the payment for matching lookup text in the mapping table.The engine runs an exact-match lookup using the concatenated string.
    • If a matching text string is found, Workday assigns the corresponding Remit-From Customer.
    • When there are conflicting text strings pointing to different customers across the fields, Workday leaves the Remit-From Customer field blank for manual entry.
  • Workday evaluates data only after it has been mapped into specific remittance advice types.
  • Grid Behavior: Each invoice matched via lookup populates its own individual row on the remittance grid and doesn’t consolidate multiple invoices into a single line.

Parsing Rules

The Workday customer payment creation job
does not natively execute parsing rules
 during its processing run but are executed upstream during statement import to isolate text into additional reference fields. Example: Additional Reference 1–5. Parsing rules and customer mappings work sequentially to resolve customer identities during processing. The parsing rules:
  • Strip down raw bank statement text such as character padding or standard bank codes, into distinct data strings and search for specific character patterns within the mapped fields, such as invoice numbers, customer names, or reference codes.
  • And populate them into target remittance advice fields on the payment record via payment rule set mappings.
  • Workday doesn’t use parsing rule.

Customer Mapping Lookup Table

  • Create a table that maps specific lookup text strings. You can use fields common customer fields such as customer aliases, bank-assigned IDs, or IBANs, or any string that you find on the bank statements for association. Map the fields to specific customer records such as Customer Reference ID, Sponsor reference ID, WID, Student Financial Account ID, Sponsor ID, or Customer ID.
  • Load the table from an EIB using the
    Put Remit-From Customer Lookup Mapping Table
     web service.

Matching Precedence Order

The customer payment rule set use this order to find a match to populate the Remit-From customer field:
  1. Payment Rule Remit-To Assignment
    : Workday applies the static Remit-To customer defined directly on the payment rule.
  2. Simple Match
    : Look specifically at data copied into Customer ID, Invoice Number, or Reference Number remittance advice fields. If an exact match is found, Workday populates the associated Remit-From Customer. If there is conflicting data among the 3 values, it will result in a blank Remit-From field.
  3. Customer Mapping Table
    : If no match is found in the prior step, the search engine evaluates the string or numbers you specify in the
    Specify Lookup Value Text
     field in the EIB Mapping table across all remittance advice types to find a match, enabling you to use other fields to map into an advice type.
    • The mapping table does not look directly at the raw bank statement data.
    • The mapping table scans through the bank statement line data that is copied over to the payment remittance advice using the customer payment rule set you define to find a match.
    • You can add up to 125,000 values to the mapping table for each upload with a maximum of 500,000 rows.
    • You cannot use calculated fields as source fields in the mapping table.
  4. Invoice Prefix Match
    : When you have a Prefix table, the engine continues to search for customer information based on the configured prefix logic. When a match is found then Workday uses the remit-from customer on that invoice to populate the field on the payment.
    1. The invoice prefix lookup logic only works if the source bank statement line data is mapped specifically to the
      Invoice Number
       remittance advice type and it doesn’t check for any other remittance advice types.
      • Configure your rules to copy bank statement line fields to the customer payment remittance advice type of Invoice Number.
      • If you use a different remittance advice type when copying the remittance information that includes the invoice, the advanced lookup functionality will not work.
    2. Workday includes the invoice prefix as part of the copied string itself.
    3. Invoice prefix matching currently requires a preceding space and assumes the prefix remains part of the target search string. For example, the prefix “INVOICE 2501234" matches while the prefix "INVOICE2501234" fails.
    4. Even if exact matching or mapping tables populate the Remit-From Customer, the Invoice Prefix Lookup still runs in the background to find and add matching invoice instances to the remittance grid without overwriting the established customer.
    • When a Remit-From customer is already populated by one of the matching steps, Workday doesn't override the Remit-From customer field on the payment.
    • If no matches are found, Workday leaves the field blank and you must add it manually.

Limitations

  • Each bank account can have only 1 rule set associated.
  • Single-Use Mapping
    : Statement addenda fields can only be mapped once, such as to a single advice type and cannot go through multi-pass parsing for reusing the addenda across payment memo fields.
  • Unmatched String Handling
    : When invoice-like tokens are present in bank statement line data but fail to match open invoices, the system copies the entire addenda string to remittance advice rather than creating individual, actionable advice entries.
  • Filter Logic
    : Addenda conditions in bank statement line rules use the AND logic, requiring you to create multiple separate rules to handle alternate prefixes. For example, you will need to create 2 separate rules if you have two prefix types "250" and "251". You cannot use the OR logic to create 1 rule.