---
sourceDocument: Yokohama Finance and Supply Chain
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/source-to-pay-operations

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama Finance and Supply Chain

ft:clusterId :

    - stpop

bundleId :

    - stpop

workflow :

    - Employee


---

# Invoice data transformation logic

# Invoice data transformation logic {#ariaid-title1}

* Release version: Yokohama
* 
* Updated January 30, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 Accounts Payable Operations integration with Document Intelligence automates the conversion of invoice and invoice line data into a system-compatible format.
This transformation logic ensures that key invoice fields such as type, dates, currency, unit price, and references are accurately interpreted and standardized for processing within ServiceNow.
Show full answer Show less  

## Type Deriving Logic

The invoice type is determined based on the presence of a purchase order (PO) value:

* If the PO value exists, the invoice is classified as **PO type**.
* If the PO value is empty, the invoice is classified as **Non-PO type**.

## Date Conversion Logic

Date formats from the invoice are converted to the ISO standard **YYYY-MM-DD**. Key points include:

* Supports various date formats such as "2nd Sep, 2022", "02-Sep-2022", and numeric formats like "09-02-2022".
* Recognizes only MM-DD-YYYY numeric formats for conversion; DD-MM-YYYY is not converted if DD is less than 12.

## Currency Conversion Logic

The system supports multiple locale currency formats, including US, European, and Indian number systems. It standardizes various currency representations by:

* Recognizing currency codes and symbols with or without spaces (e.g., "76 EUR", "76€", "EUR76").
* Handling number formatting with commas, dots, or other separators for grouping and decimals.
* Determining invoice currency based on purchase order currency for PO invoices or legal entity local currency for Non-PO invoices, defaulting to system currency if necessary.

## Unit Price Conversion Logic

Unit prices with currency symbols or codes are converted to a standardized numeric format, supporting locale-specific formats such as "1,00,025.10" or "$1,000,25.10". This ensures consistent unit price values regardless of invoice origin.

## Decimal Conversion Logic

The application interprets decimal and thousand separators based on locale conventions (e.g., European commas as decimals, dots as thousands). It converts values accordingly, but if only a single decimal separator is present, the value is set to empty to avoid incorrect conversions.

## Reference Field Value Fetching Logic

The system populates key reference fields on the invoice by applying specific matching rules:

* **Legal Entity:** Determined from invoice billing address elements in hierarchical order (Bill to company, City, State, Country, Zip).
* **Purchase Order:** Extracted by cleaning prefixes and matching the remaining value to ERP purchase order numbers.
* **Supplier:** Matched against the Supplier table with exact or partial name matching combined with address details to identify the correct supplier.
* **Country:** Taken directly from the invoice or populated with ISO short or long country names if missing.
* **Subtotal, Tax, Other Charges:** Numeric values are grouped and converted based on decimal separator rules; negative amounts are identified including those indicated by brackets or trailing minus signs, triggering classification as Credit memo invoices.

## Practical Benefits for ServiceNow Customers

This transformation logic enables ServiceNow customers to automate invoice data ingestion accurately, reducing manual corrections and errors. It supports diverse invoice formats and international standards, ensuring reliable processing across global operations. By leveraging this logic, customers can expect streamlined accounts payable workflows with enhanced data consistency and compliance.  
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 {#invoice-data-trans-logic__section_nwm_yrb_gyb}

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.
{#invoice-data-trans-logic__ul_n3w_bsb_gyb}

## Date conversion logic {#invoice-data-trans-logic__section_acr_x4m_1xb}

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.
{#invoice-data-trans-logic__ul_i5l_sgn_1xb}
{#invoice-data-trans-logic__table_bfw_szm_1xb__entry__2}

| 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 |
[Table 1. Invoice date conversions]

{#invoice-data-trans-logic__table_bfw_szm_1xb}

## Currency conversion logic {#invoice-data-trans-logic__section_qyh_hpm_1xb}

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.
{#invoice-data-trans-logic__table_tbj_tzm_1xb__entry__3}

| 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 |
[ ]

{#invoice-data-trans-logic__table_tbj_tzm_1xb}  
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.
{#invoice-data-trans-logic__ul_sks_xnb_gyb}

## Unit Price conversion logic {#invoice-data-trans-logic__section_afy_hpb_gyb}

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.
{#invoice-data-trans-logic__table_bfy_hpb_gyb__entry__2}

| 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 |
[Table 2. Unit price conversion]

{#invoice-data-trans-logic__table_bfy_hpb_gyb}

## Decimal conversion logic {#invoice-data-trans-logic__section_q5g_ctm_1xb}

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](https://www.servicenow.com/docs/access?context=currency&version=yokohama&pubname=yokohama-platform-administration&ft:locale=en-US).
{#invoice-data-trans-logic__table_ch1_5zm_1xb__entry__2}

| Decimal format mentioned in the incoming invoice | Converted decimal format |
|-|-|
| 1,000,25.10 | 100025.10 |
| 1,00,025.10 | 100025.10 |
| 100,251 | 100,251 |
| 10.102,510 | 10102.51 |
| 10.10.102,510 | 1010102.51 |
| 100,251 |   |
| 100.251 |   |
[Table 3. Decimal conversion]

{#invoice-data-trans-logic__table_ch1_5zm_1xb}

## Logic to fetch reference field values {#invoice-data-trans-logic__section_qwf_3tm_1xb}

{#invoice-data-trans-logic__table_rxz_svm_1xb__entry__2}

| 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 {#invoice-data-trans-logic__ol_f5w_zvm_1xb} |
| 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 {#invoice-data-trans-logic__ul_xcd_3wm_1xb} |
| 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. {#invoice-data-trans-logic__ul_yyy_bym_1xb}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) {#invoice-data-trans-logic__ul_xbc_b5k_ydc}In such cases, the invoice is considered as of type Credit memo. {#invoice-data-trans-logic__ul_rl3_3rp_zzb} |
[Table 4. Logic to fetch reference field values]

{#invoice-data-trans-logic__table_rxz_svm_1xb}