Converting Inbound E-Documents into Transaction Records

Converting an E-Document into Vendor Bill Linked to Purchase Order

The process of converting purchase order to vendor bill is viewed from the perspective of the NetSuite user being a customer, who purchased items or services from a vendor. In this scenario, the NetSuite user initially sends a purchase order to a vendor, by outbound electronic invoicing. The purchase order is received by the vendor and processed on their side. The vendor will enter the details of the purchase order into their system and eventually generates an invoice record, which is then converted into an XML e-document and returned to the NetSuite user. The XML e-document from the vendor is received by the NetSuite user through the inbound electronic invoicing feature. The NetSuite user uploads the received XML file to NetSuite as an inbound e-document record. It is this inbound e-document record that will undergo conversion to a vendor bill that is linked to the original purchase order.

Converting an E-Document into Vendor Credit Linked to Vendor Bill of a Purchase Order

The inbound e-document conversion process can create a vendor credit from a purchase order when the incoming e-document references an existing purchase order having at least one open and approved vendor bill.

During conversion, the system searches for the purchase order referenced in the inbound e-document. After it identifies the matching purchase order, the system searches for approved and open vendor bills associated with that purchase order. If multiple vendor bills exist, the system selects the first vendor bill that is both open and approved.

The system then transforms the selected vendor bill into a vendor credit and applies the information from the inbound e-document according to the configured conversion rules.

Important:

As part of the unified inbound template, the system sources the purchase order number from the cac:OrderReference//cbc:ID tag or the cbc:BuyerReference tag in the PEPPOL e-document XML. The system gives priority to the value in the cac:OrderReference//cbc:ID tag. If that tag is not present, the system uses the value from the cbc:BuyerReference tag. If both cac:OrderReference//cbc:ID and cbc:BuyerReference are blank, then a standalone vendor bill/ vendor credit transaction is created.

Handling Applied and Unapplied Amounts in Credit Note to Vendor Credit Conversion

During inbound conversion of a Credit Note to a Vendor Credit, the system determines the Applied and Unapplied amounts based on how the Vendor Credit is created.

Vendor Credit Created from an Existing Vendor Bill

When a Credit Note is associated with a purchase order that has a related Vendor Bill, the system transforms the Vendor Bill into a Vendor Credit.

Credit Note amount is greater than the Vendor Bill amount:

The Vendor Bill amount is recorded as the Applied amount.
The remaining Credit Note amount is recorded as the Unapplied amount.
The Vendor Bill status changes to Fully Billed.

Credit Note amount equals the Vendor Bill amount:

The entire Credit Note amount is recorded as the Applied amount.
The Unapplied amount is 0.
The Vendor Bill status changes to Fully Billed.

Credit Note amount is less than the Vendor Bill amount:

The entire Credit Note amount is recorded as the Applied amount.
The Unapplied amount is 0.
The Vendor Bill remains Open because it has not been fully credited.

Standalone Vendor Credit

When the system creates a Vendor Credit without an associated Vendor Bill:

The entire Credit Note amount is recorded as the Unapplied amount.
The Applied amount is 0.

Purchase Order Items and Expenses in Inbound E-Documents

As an item or an expense is required in a purchase order, either of them must also be included in the e-document for conversion; otherwise, conversion to vendor bill won't proceed.

In addition, items or expenses specified in the inbound e-document must include relevant details:

For items, either the vendor code or vendor code/name must be included, depending on whether the Multiple Vendors feature is enabled or not.
For expense, the amount must be included, and it is that the Default Expense Account in the vendor record has a value. If there are specified amounts with no corresponding accounts, the Default Expense Account is automatically made the default account in the new vendor bill created from conversion.

For more details about the prerequisites for converting inbound e-documents with purchase orders items or expenses, see the following topic.

Prerequisites and Conditions for Conversion

Permission to Convert E-Documents

Your user role must have the permission to convert e-document records into NetSuite transactions. For more information about granting a role the permission to perform inbound e-document conversion, see Setting Up Custom Roles that can Convert Inbound E-Documents.

Status of Purchase Order

The inbound XML e-document must not be linked to a purchase order whose status is fully billed, unapproved, rejected, cancelled or closed. Otherwise, the conversion will fail. Conversion will also fail if the vendor in the inbound XML e-document is different from the vendor in the purchase order.

Inbound E-Document has Reference Number with Mapping in the Template

The Reference Number must be included in the inbound XML e-document and the e-document template must contain the mapping for the reference number. Without the reference number in the inbound XML e-document or the correct reference number mapping in the template, conversion of the e-document will fail.

Inbound E-Document has Purchase Order Number and the Template has Mapping to the createdfrom Field

The Purchase Order Number must be included in the inbound XML e-document and the e-document template must contain the mapping for the createdfrom field. Without the Purchase Order Number in the inbound XML e-document or the correct reference number mapping in the template, conversion will result in a stand-alone vendor bill or vendor credit. See Converting an Inbound E-Document Without a Purchase Order Number.

Bypassing Purchase Order Number

When converting an inbound XML e-document into a vendor bill, you can bypass the purchase order number validation if:

The purchase order number is included in the inbound XML e-document.
The e-document template contains the mapping for the createdfrom field.
No matching purchase order number is found in the account.

You can bypass the validation (checking if the purchase order number in the XML e-document is present in the account) from the E-Document Subsidiary preferences.

To bypass purchase order number validation during inbound conversion:

Go to Setup > E-Documents > Electronic Invoicing Preferences.
Click the subsidiary of the vendor for which you want to bypass purchase order (PO) validation.
Click Edit.
(Optional) In the Bypass PO# Validation in Inbound Conversion field, you can select Yes if you want to bypass the purchase order number validation and create a standalone vendor bill if a matching purchase order number is not found in the account.

By default, the field value is No which refers to no matching purchase order number is found when converting an inbound e-document into a vendor bill. So, no vendor bill will be created and conversion will throw an error.

Purchase Order must have either an Item or Expense

The reference purchase order of the inbound e-document for conversion, must have either an item or expense specified. Without item or expense, the inbound e-document won't be converted. Moreover, purchase order items or expenses must have required details included in the inbound e-document for conversion. The required details of items or expenses are discussed in the following sections.

Required Account and Amount for an Expense

If the XML e-document has an expense line, the required Account and Amount fields of the bill must have values. The Account field of the expense line references the value of Default Expense Account on the Financial subtab of the vendor record. Therefore, the vendor must have a Default Expense Account setup or the conversion will fail.

Required Vendor Code for Item Records

If the purchase order has item records, the vendor code of these item records must be included in the inbound XML e-document. If the Multiple Vendors feature is enabled during conversion, you must enter the Vendor Code on the Vendors subtab of the item record. The vendor code will be used to map the items to their corresponding vendor. If the vendor code in the XML e-document does not match any vendors, conversion will fail. The vendor code field is highlighted in the following screenshot.

Inventory Item record with Purchase/Inventory subtab shown

Required Vendor Code/Name for Item Records

If the Multiple Vendors feature is disabled, the vendor code/name on the main tab of item records must be included in the inbound XML e-document. Otherwise, the conversion will fail. If two or more items have the same vendor code/name, implying duplicates, the conversion will fail. The vendor code/name field is highlighted in the following screenshot.

Inventory Item record with Vendor Code/Name field highlighted

Inbound E-Document has Billing Reference and the Template has Mapping to the Apply Subtab of CreditMemo

If the billing reference is included in the inbound XML e-document, the e-document template must contain the mapping for the invoice ID of Apply subtab. Without the existence of valid bill referenced to the Invoice ID present in the billing reference of XML, the inbound XML e-document conversion will fail. But without the billing Reference, the inbound XML e-document conversion will still result in a stand-alone vendor credit.

Handling Unapproved Items as Expenses

The unified Inbound template (template created under builder kit) for vendor bill and vendor credit supports both items and expenses.

In the file cabinet, you can go to SuiteApps > com.NetSuite.electronicinvoicing > Sample Templates > Builder > Templates and update your existing templates with the contents of these files.

There are two scenarios for conversion:

Invoice to bill
Credit memo to bill credit

Electronic Invoicing derives expenses from inbound XML by following a defined matching order for each invoice line. First, it attempts to match the value in cac:InvoiceLine/cac:Item/cbc:Name with a Vendor Code in the item records. If it finds a match, the system creates the line as an item in the Vendor Bill. If it does not find a match, it checks cac:InvoiceLine/cac:Item/cac:BuyersItemIdentification/cbc:ID. If this value matches an expense category (by ID or name), the system creates the line as an expense using the mapped expense account.

If neither match succeeds, the system treats the line as an expense only when you enable the option to allow unmatched items to default to the vendor's default expense account. In this case, it assigns the vendor's default expense account. If the system cannot find any match and no valid default expense account exists, it fails to create the Vendor Bill and returns an error.

Important:
The Unmatched items will default to the vendor's default expense account box in the Electronic Invoicing Preferences page ensures that the system associates all expenses in the inbound XML with the vendor's default expense account when the BuyersItemIdentification ID (also known as the Expense Category) is not specified for those expenses.

You must set the Unmatched items will default to the vendor's default expense account to 'yes' to link expenses to default account.

Support for Location, Class and Department in Inbound E- Document Conversion

The inbound e-document conversion process supports Location, Class, and Department (LCD) fields when it creates vendor bills and vendor credits. LCD values help classify transactions and transaction lines for accounting and reporting purposes. For organizations that require these fields, the system uses LCD sourcing to help prevent transformation failures.

The system can source LCD values from multiple locations during inbound conversion. It evaluates each available source in a fixed priority order and applies the first valid value it finds. This behavior applies to both transaction header fields and transaction line fields during standalone transaction creation and transaction transformation.

LCD Value Sourcing Priority for Items and Expenses

During inbound e-document conversion, the system sources Location, Class, and Department values in the following order:

Inbound template mapping
Source transaction (Purchase order to Vendor Bill), if applicable.
Item record (applicable for items)
Subsidiary preferences

The system always checks sources in this order for header and each line individually. When it finds a valid value in a higher-priority source, it stops checking lower-priority sources for LCD.

For example, if the inbound template mapping defines a Department value, NetSuite uses that value for the Department field and does not check the source transaction, item record, or subsidiary preferences. If Location and Class values are not defined in the inbound template mapping, NetSuite leaves those fields blank.

LCD Values in Inbound Template Mapping

You can use the Inbound Generic Starter Plugin CDS to define Location, Class, and Department (LCD) values for both header-level and line-level records in the Inbound Generic PEPPOL template.

The Inbound Generic Starter Plugin CDS and its template mapping, configured in the E-document Template record, determine the LCD values used during inbound conversion.

Important:

Return both header-level and line-level LCD values, even if you use LCD values at only one level. This requirement applies to both header and line processing. For example, if you provide Location and Class in line-level, then make sure you provide Location and Class only in the header level as well.

LCD Values in Subsidiary Preferences

You can define Location, Class, and Department (LCD) values in the subsidiary preference record.

During inbound conversion, NetSuite uses the subsidiary preference values when LCD values are not available from the inbound mapping, source transaction, or item record.

The LCD values defined in the subsidiary preference record apply LCD to both header-level and line-level, including item and expense lines.

LCD Behavior During Transaction Creation and Transformation

The inbound conversion process can create a new standalone transaction or transform an existing transaction.

Vendor Bill Standalone Transaction Creation

When the system cannot match the inbound e-document to an existing purchase order, it creates a standalone Vendor Bill, provided that Bypass PO# Validation in Inbound Conversion box is checked in the subsidiary preferences for the corresponding subsidiary. In this scenario, the system sources LCD values from the inbound template mapping, item records, and subsidiary preferences according to the defined priority order.

Vendor Credit Standalone Transaction Creation

During inbound conversion if the purchase order is found to be empty, system will create a standalone vendor credit having LCD values from the inbound template mapping, item records, and subsidiary preferences according to the defined priority order.

Purchase Order to Vendor Bill Transformation

When the system matches an inbound e-document to a Purchase Order, it transforms the Purchase Order into a Vendor Bill. In this scenario, the system can source LCD values from the inbound template mapping, the source Purchase Order, item records, and subsidiary preferences

Vendor Bill to Vendor Credit Transformation

When the system transforms a Vendor Bill into a Vendor Credit, it evaluates LCD values using the same sourcing hierarchy. The system can use values from the inbound template mapping, the source Vendor Bill, item records, and subsidiary preferences based on the available data in the transformation flow.

Header Level and Line Level LCD Processing

The system supports LCD values at both the transaction header level and the transaction line level.

During processing, the system evaluates header-level values and line-level values independently according to the sourcing hierarchy.

Handling Partially Populated Line Level LCD Values

The system can populate missing line-level LCD values from header-level values when only some LCD values are available at the line level.

For example, if a line item contains Location and Class values but does not contain a Department value, and the source transaction contains a Department value at the header level, the system uses the header-level Department value for the transaction line.

The system evaluates each LCD value independently and applies the highest-priority available value based on the defined sourcing hierarchy.

If the system finds valid LCD values at the line level, it applies those values to the corresponding transaction line. If line-level values are not available, the system uses the next valid fallback source based on the defined priority order.

LCD Behavior When Values Exist in Multiple Sources

The system may find LCD values in more than one source during processing. In these cases, it applies the value from the highest-priority source.

For example:

If the inbound template mapping contains LCD values and the source purchase order also contains an LCD value, the system uses the inbound template mapping value.
If the source transaction contains a Class value and the item record also contains a Class value, the system uses the source transaction value. The system uses the item record value only when the item is not present on the source transaction or when the LCD is blank on the source transaction line.
If the inbound template mapping, source transaction, and item record do not contain LCD values, the system uses the LCD values defined in subsidiary preferences.

This behavior helps the system assign LCD values consistently and predictably during inbound conversion.

Expense Line Behavior and Limitations

Expense lines follow different processing rules than item lines during transaction transformations.

During the first transformation of a source transaction, expense lines can inherit Location, Class, and Department (LCD) values from the source transaction if LCD values are not defined in the inbound template mapping of the e-document template. The system does not carry forward these values in subsequent transformations.

During subsequent transformations, the system treats expense lines as new records. Consequently, expense lines do not inherit LCD values from the original source transaction in later transformations. Instead, the system sources LCD values again using the standard priority order and the available fallback sources. For more information, see, LCD Value Sourcing Priority for Items and Expenses.

Tax Code Limitation for Inbound Transactions

During inbound conversion, the Electronic Invoicing SuiteApp does not derive or map tax details from the XML payload to the inbound transaction.

Tax codes are assigned as follows:

Legacy Tax Accounts:
- For item and expense lines on inbound transactions, the tax code is determined based on:
  - The tax code selected for the subsidiary in the vendor record.
  - The Set Up Taxes for Country configuration. (Setup > Accounting > Set Up Taxes).
- If the tax code selected in the vendor record or Set Up Taxes page is not applicable then the system defaults to a non-taxable code.
SuiteTax Accounts:

For SuiteTax accounts, tax codes on inbound transactions are determined based on the nexus associated with the vendor subsidiary.