• 20/10/2026
  • 11 minutes to read

Payment reference rule examples

Use these examples as templates when you configure payment reference rules in Continia Banking. Each example shows how to match common payment reference formats.

Example 1: Finnish Reference Number (FI)

  • Format: Numeric, includes a check digit (Modulus 10)
  • Sample Reference: 12345672

Configuration

  • Validation Pattern: ^\d{8}$
  • Check Digit: Enabled (Modulus 10)
  • Direct Match: Enabled
  • Match to Table: Customer Ledger Entry
  • Match to Field: Document No.

Note

When Direct Match is enabled, Reference Start Position and Reference Length are automatically cleared and not used.

Example 2: Swedish OCR Number

  • Format: Numeric, variable length, check digit (Modulus 10)
  • Sample Reference: 12345678903

Configuration

  • Validation Pattern: ^\d{10,12}$
  • Check Digit: Enabled (Modulus 10)
  • Direct Match: Enabled
  • Match to Table: Customer Ledger Entry
  • Match to Field: Document No.

Example 3: Norwegian KID Number

  • Format: Numeric, variable length, check digit (Modulus 10 or 11)
  • Sample Reference: 12345678903

Configuration

  • Validation Pattern: ^\d{5,25}$
  • Check Digit: Enabled (Modulus 10 or 11)
  • Direct Match: Enabled
  • Match to Table: Customer Ledger Entry
  • Match to Field: Document No.

Example 4: Reference with embedded document type

  • Format: "INV2024001" (where "INV" is the document type indicator, "2024001" is the reference)
  • Sample References:
    • INV2024001 (Invoice)
    • CM2024002 (Credit Memo)

Configuration

  1. Create document type mappings:
    • Code = "INV_MAPPING", Document Type Indicator = "INV", Document Type = "Invoice"
    • Code = "CM_MAPPING", Document Type Indicator = "CM", Document Type = "Credit Memo"
  2. Configure the rule:
    • Validation Pattern: ^[A-Z]{2,3}\d{7}$
    • Direct Match: Disabled
    • Reference Start Position: 4
    • Reference Length: 7
    • Match Document Type: Enabled
    • Document Type Start Position: 1
    • Document Type Length: 3
    • Match to Table: Customer Ledger Entry
    • Match to Field: Document No.
  3. Link mappings to the rule:
    • Use the Related Document Types to link "INV_MAPPING" and "CM_MAPPING".

Expected behavior

The system extracts "2024001" for matching and identifies it as an invoice document type.

Example 5: Bank-specific reference format

  • Format: Varies by bank
  • Examples:
    • Bank A: 10-digit reference ^\d{10}$
    • Bank B: 12-digit reference ^\d{12}$

Configuration:

  • Create separate rules filtered by Bank Code:
    • Rule 1: Bank Code BANKA
    • Rule 2: Bank Code BANKB

Each rule applies only to transactions from the specified bank.

Example 6: Modulus 10 Recursive check digit

  • Format: Scandinavian payment reference using Modulus 10 recursive check digit
  • Sample Reference: 1234567890 (where the last digit is the check digit)

Configuration

  • Validation Pattern: ^\d{10,15}$
  • Check Digit: Enabled
  • Check Digit Algorithm: Modulus 10 recursive
  • Check Digit Position: 10 (position of the check digit)
  • Check Digit Calc. Start Pos.: 1
  • Check Digit Calc. Length: 9
  • Direct Match: Enabled
  • Match to Table: Customer Ledger Entry
  • Match to Field: Document No.

Expected behavior

The system validates the check digit using the Modulus 10 recursive algorithm before matching the reference.

Example 7: Combined filters

  • Format: CAMT053 statements from specific bank with ISO transaction codes
  • Sample Reference: 98765432

Configuration

  • Validation Pattern: ^\d{8}$
  • Direct Match: Enabled
  • Statement Type: CAMT053
  • Bank Code: NORDEA
  • Domain Code: PMNT
  • Family Code: RCDT
  • Sub-Family Code: ESCT
  • Match to Table: Customer Ledger Entry
  • Match to Field: Document No.

Expected behavior

This rule only applies to:

  • CAMT053 statements
  • From bank NORDEA
  • With ISO transaction code PMNT-RCDT-ESCT (payment received credit transfer)

Example 8: Convert a 32‑character hex value to a GUID

  • Format: 32‑character hexadecimal string without hyphens
  • Sample Reference: 00112233445566778899aabbccddeeff
  • Converted Format: 00112233-4455-6677-8899-aabbccddeeff

Configuration

  1. Create the validation pattern:

    • Validation Pattern Code: INVALIDGUID

    • Description: GUID without '-'

    • Pattern Text:

      (?<![0-9a-f])[0-9a-f]{32}(?![0-9a-f])

    This pattern identifies transaction text that contains exactly 32 hex characters.

  2. Create the transformation pattern:

    • Pattern Code: GUID

    • Description: Add - to GUID

    • Pattern Text:

      (?<=[0-9a-f]{8})(?=[0-9a-f]{24}$)|(?<=[0-9a-f]{12})(?=[0-9a-f]{20}$)|(?<=[0-9a-f]{16})(?=[0-9a-f]{16}$)|(?<=[0-9a-f]{20})(?=[0-9a-f]{12}$)

    The pattern marks positions where hyphens should be inserted to form the standard GUID format.

  3. Create a Continia Banking Import Transformation Rule:

    • Code: ADD-GUID
    • Description: Add missing '-' to GUID
    • Transformation Type: Regular Expression – Replace
    • Find Value by Pattern: GUID
    • Replace Value: -
    • Test Input: 00112233445566778899aabbccddeeff
    • Expected Result: 00112233-4455-6677-8899-aabbccddeeff

  4. Create the payment reference rule:

    • Code: ING
    • Description: GUID Reference
    • Search Field Template: DESCTRANSACDETAILS
    • Validation Pattern Code: INVALIDGUID
    • Match to Table: Bank Account Ledger Entry
    • Match to Field: CTS‑CB Unique ID
    • Transformation Rule: ADD-GUID
    • Direct Match: Enabled

Expected behavior

The system detects the 32‑character hex value, converts it to a hyphenated GUID, and performs a direct lookup against the CTS‑CB Unique ID field in the Bank Account Ledger Entries.

Example 9: Find multiple entries with the same reference number

Use this option when multiple open entries share the same payment reference number, such as a collective invoice number, and a single payment may relate to all of them.

Customer ledger entries

CustomerRemaining AmountPayment Reference
Customer AEUR 100.00ABC12345UX9999
Customer BEUR 110.00ABC12345UX9999
Customer CEUR 120.00ABC12345UX9999

Imported payment

AmountPayment Reference
EUR 315.00ABC12345UX9999

Rule configuration

  • Match Type: Direct Matching
  • Search Field: Payment Reference No.
  • Allow Multiple Applications: Enabled

Result

The payment reference rule finds all customer ledger entries with the payment reference ABC12345UX9999 and creates payment application proposals for all matching entries.

Because the imported payment amount (EUR 315.00) doesn't match the total remaining amount of the found entries (EUR 330.00), the entries are shown as application proposals on the Payment Application Review page but aren't applied automatically. You can then review the proposed entries and apply the correct ones manually.

If the payment amount had been EUR 330.00, all three entries would have been applied automatically.

Example 10: Remove a prefix from the payment reference before matching

The payment reference has a prefix that isn’t part of the document number. For example, the reference is RG12345 and the document number is 1012345.

The payment reference rule is set up correctly, but the reference doesn’t match because of the prefix. To fix this, add a transformation rule to the payment reference rule. The transformation rule changes the reference string before the payment reference rule is applied. You can use it to remove prefixes and suffixes, strip symbols, or make other changes. Transformation rules support both plain text replacement and regular expressions.

Configuration

  1. On the Payment Reference Rules page, create the payment reference rule. On the Matching FastTab, in the Transformation Rule field, click the three dots to create a new rule.

  2. On the Continia Banking Import Transformation Rules page, on the action bar, click New.

  3. For the rule, you can use one of these transformation types:
    Replace text:

    • Transformation Type: Replace text
    • Find Value: RG
    • Replace Value: 10

    Replace using a regular expression:

    • Transformation Type: Replace by using regular expressions
    • Find Value by Pattern: ^RG
    • Replace Value: 10

  4. Use the Test Input and Expected Result fields to check that the transformation gives the result you expect.

Expected behavior

The system applies the transformation rule to the payment reference (RG12345 becomes 1012345), then applies the payment reference rule. The changed reference matches the document number in Business Central.

Example 11: Match part of a reference using wildcards

Use this option when the reference you receive from the customer is only part of the value stored on the ledger entry, such as a reference surrounded by a prefix and a suffix.

Format: Numeric reference embedded in a longer value

Sample reference: 34882982

Sample value on the ledger entry: wEcHf34882982-hj

Configuration

Create the transformation pattern as described in Regular Expression Patterns:

  • Pattern Code: REF8
  • Description: Eight-digit reference
  • Pattern Text: (\d{8})

Create a Continia Banking Import Transformation Rule:

  • Code: WILDCARD-REF
  • Description: Add wildcards around the reference
  • Transformation Type: Replace by using regular expressions
  • Find Value by Pattern: REF8
  • Replace Value: ?????$1???
  • Test Input: 34882982
  • Expected Result: ?????34882982???

Create the payment reference rule:

  • Validation Pattern: ^\d{8}$
  • Direct Match: Enabled
  • Match to Table: Customer Ledger Entry
  • Match to Field: Replace by using regular expressions
  • Transformation Rule: WILDCARD-REF

Expected behavior

The transformation rule turns the extracted reference 34882982 into ?????34882982???. Because the transformed reference contains wildcards, the rule matches the target field with a filter expression instead of an exact value, and finds the entry with the reference wEcHf34882982-hj.

The wildcards work as follows:

  • ? matches exactly one character.
  • * matches any number of characters.

Use * when the number of characters before or after the reference varies. A transformed reference that is longer than the target field can still match when the extra length comes from *.

Note

Wildcards are only applied when the payment reference rule has a transformation rule. Without a transformation rule, ? and * in a reference are treated as literal characters.

Tip

To see the result of the transformation before you use the rule, check Transformed Result in the test section on the Payment Reference Rule page or the Payment Reference Test page.

Setting up a payment reference rule
Validation pattern codes for matching payment references
Default payment reference rules
Configuring check digit validation
Payment reference rules FAQ