Invoice data transformation logic

  • Release version: Zurich
  • Updated July 31, 2025
  • 6 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Invoice data transformation logic

    The Invoice data transformation logic in the Accounts Payable Operations integration with Document Intelligence standardizes invoice and invoice line field values from invoice documents into a format supported by the processing system. This ensures consistent and accurate data handling for invoices within ServiceNow's Zurich release.

    Show full answer Show less

    Key Features

    • Type Deriving Logic: Determines invoice type based on purchase order presence; assigns "PO type" if a purchase order exists, otherwise "Non-PO type."
    • Date Conversion: Converts various invoice date formats to the ISO standard (YYYY-MM-DD), supporting formats like "2nd Sep, 2022," "09-02-2022," and others while excluding ambiguous DD-MM-YYYY formats where DD < 12.
    • Currency Conversion: Supports multiple locale formats (US, European, Indian) and normalizes currency amounts and codes. It matches currency symbols or codes against the active currency table and applies defaulting logic based on invoice type:
      • PO invoices use purchase order currency or fallback to system currency.
      • Non-PO invoices use legal entity’s local currency or fallback to system currency.
    • Unit Price Conversion: Handles different locale number formats and converts unit prices that include currency symbols or codes into a normalized numeric format for processing.
    • Decimal Conversion: Manages decimal and thousand separators according to locale, ensuring accurate numeric conversions in invoice data. It detects multiple separators and converts accordingly; if only a single decimal separator exists, the value may be set empty to avoid errors.
    • Reference Field Value Fetching: Implements logic to accurately populate key reference fields:
      • Legal Entity: Derived from bill-to company, address, and geographic data in prioritized order.
      • Purchase Order: Matches invoice PO value (ignoring prefixes) with ERP purchase orders to populate PO fields.
      • Supplier: Matches supplier names via exact or partial matches combined with address details to ensure correct supplier identification.
      • Country: Uses invoice country value or defaults to ISO standard country names if missing.
      • Subtotal, Tax, Other Charges: Applies numeric grouping rules and handles negative amounts and credit memos by recognizing negative signs in various formats.

    Practical Implications for ServiceNow Customers

    This transformation logic enables customers to automatically and accurately process invoice data from diverse formats and locales without manual intervention. It ensures that invoice types, dates, currencies, prices, and reference fields align with system expectations, reducing errors and improving efficiency in Accounts Payable workflows. Customers can expect improved data quality and streamlined invoice processing that supports both PO and Non-PO invoices with locale-aware conversions.

    Understanding this logic helps customers troubleshoot and validate invoice data handling within ServiceNow’s invoice management, especially when integrating with Document Intelligence and ERP systems.

    Accounts Payable Operations integration with Document Intelligence converts the invoice and invoice line field values from the invoice document to a format supported by the system that processes the invoice.

    Type deriving logic

    The application includes the following logic for deriving the type field on the invoice.

    • Considers the purchase order value in the invoice stage record
    • If the purchase order value isn’t empty, then the invoice type is set to PO type.
    • If the purchase order value is empty, then the invoice type is set to Non- PO type.

    Date conversion logic

    The application includes the following logic for converting date formats mentioned in the invoice document:
    • Considers YYY-MM-DD as the ISO format and the system format for date conversion.
    • Considers dates only in MM-DD-YYYY format for conversion.
    • Doesn’t consider dates in DD-MM-YYYY format if DD is less than 12.
    Table 1. Date conversion logic
    Date format in the incoming invoice Converted date format
    2nd Sep, 2022 2022-09-02
    3rd September, 2022 2022-09-02
    02-Sep-2022 2022-09-02
    02-Sept-2022 2022-09-02
    Sept-02-2022 2022-09-02
    Sep-02-2022 2022-09-02
    09-02-2022 2022-09-02
    02-09-2022 2022-02-09
    09/02/2022 2022-09-02
    02/09/2022 2022-02-09

    Currency conversion logic

    The application supports different locale such as US, European and Indian number systems. For example, "X,XXX.XXX", "X.XXX,XX", "XX,XX.XXX" where X is a single-digit positive number.

    Table 2. Currency conversion logic
    Scenario Currency format in the incoming invoice Converted currency format
    Amount followed by a space and the currency code 76 EUR 76 EUR
    Amount followed by a space and the currency symbol 76 € 76 EUR
    Currency code followed by multiple spaces and the amount EUR 76 76 EUR
    Currency symbol followed by multiple spaces and the amount € 76 76 EUR
    Amount without a currency code or symbol 76 76 (followed by the purchase order currency or the session currency)
    Amount separated by comma, dot or any other grouping or decimal separator followed by a space and the currency code 7.123.456,99 EUR 7123456.99 EUR
    Amount followed by the currency code without any space 76EUR 76 EUR
    Amount followed by the currency symbol without any space 76€ 76 EUR
    Currency code followed by the amount without any space EUR76 76 EUR
    Currency symbol followed by the amount without any space €76 76 EUR
    The application first looks for the active unique currency code in the Currency [fx_currency] table when an incoming invoice amount has a currency symbol or code. If multiple currency matches are found or the incoming invoice amount has no currency code or symbol, then the application runs the defaulting currency logic depending on the invoice type as follows.
    • PO invoice - Searches for purchase order and related currency, and sets the invoice currency to purchase order currency. In case of missing purchase order or related currency, the invoice currency is set to system currency.
    • Non- PO invoice - Searches for legal entity and local currency, and sets the invoice currency to the legal entity's local currency. In the case of missing legal entity and local currency, the invoice currency is set to system currency.

    Unit Price conversion logic

    The application supports different locale such as US, European and Indian number format locale. For example, "X,XXX.XXX", "X.XXX,XX", "XX,XX.XXX" where X is a single-digit positive number.

    If the incoming invoice unit price consists of currency symbol or code present in Currency [fx_currency] table, then the unit price is converted. For example, $ XX,XXX,XXX.XX or USD XX,XX,XXX.X, where X is a single-digit positive number.

    Table 3. Unit Price conversion logic
    Unit price mentioned in the incoming invoice Converted unit price
    1,000,25.10 100025.10
    1,00,025.10 100025.10
    $1,000,25.10 100025.10
    1,000,25.10 $ 100025.10
    USD1,00,025.10 100025.10
    1,00,025.10 USD 100025.10

    Decimal conversion logic

    The application supports different locale such as US, European and Indian decimal format locale. For example, "X,XXX.XXX", "X.XXX,XX", "XX,XX.XXX" where X is a single-digit positive number.

    Currency groupings on invoice and invoice lines are determined based on the user system locale settings. European currencies consider comma as a decimal separator and dot as a thousand separators. In some cases, various characters can also be used as grouping separator. The incoming invoice and invoice lines present in [sn_ap_ic_invoice_stage] and [sn_ap_ic_invoice_line_stage] tables are converted based on the positioning of decimal and thousand separators.
    Note:
    During conversion, for numbers such as 100,251 and 100.251, the system checks for other decimal separators mentioned in the invoice, and converts it to the appropriate decimal format. If the invoice contains fields with a single decimal separator, then conversion doesn’t apply for the invoice, and the value is set to empty as shown in the following table.
    For more information on currency conversion, see Currency administration.
    Table 4. Decimal conversion logic
    Decimal format mentioned in the incoming invoice Converted decimal format
    1,000,25.10 100025.10
    1,00,025.10 100025.10
    10.102,510 10102.51
    10.10.102,510 1010102.51
    100,251
    100.251

    Logic to fetch reference field values

    Table 5. Reference field value logic
    Reference Field Logic to fetch the field value
    Legal Entity The system fetches the value by checking the following values in the order listed:
    1. Bill to company
    2. Street, City, State, Country, Zip
    3. City, State, Country, Zip
    4. State, Country, Zip
    5. Country, Zip
    6. Country
    7. Zip
    Purchase Order The system does the following:
    • The system considers the purchase order value mentioned in the invoice stage
    • If the purchase order value is prefixed with special characters, alphabets or zeroes, then the application ignores the prefixes and matches the remaining purchase order value with the ERP number from the purchase order table
    • If a unique purchase order is found, then the application populates the purchase order in the invoice
    Supplier The system does one of the following:
    • The system considers the value mentioned in the invoice and does a complete match with supplier in Supplier table.
    • If the invoice contains a purchase order associated with the supplier, the application matches with the supplier name mentioned in the invoice with the supplier name of purchase order and populates the supplier.
    • If the invoice document contains supplier name with more than two words, the application performs partial name match against the supplier details in the supplier table along with street address or city. Example. If the invoice document contains supplier name as XX Corp, and the supplier name in the supplier table is XX Ltd, the application matches XX in supplier table along with the address and populates the invoice document with the corresponding supplier.
    If a unique supplier record is found in any of the above, then the application populates the supplier in the invoice.
    Country The system does one of the following:
    • Considers the value mentioned in the invoice
    • If this value isn’t mentioned in the invoice, it populates the International Organization for Standardization (ISO) short country name or the ISO long country name
    Subtotal, Tax amount, Other charges The system does the following:
    • If the invoice contains XX.XXX,XXX the application groups the numeric to four digits after decimal separator.
    • If the invoice contains three numeric digits after the separator, the application sets the invoice fields to empty.
    • If the invoice contains a combination of decimal and thousand separators in a form, the application defaults to the numeric value to the decimal separator.
    • If the invoice contains negative amount or negative quantity, then the DocIntel transformation logic is updated to extract negative amounts where the negative sign is either:
      • Present after the value (header or line level)
      • Present within a bracket (header or line level)
      In such cases, the invoice is considered as of type Credit memo.