CIB Configuration Documentation

Purpose of the document

This document and its subpages describe the standard Rossum Coupa integration configuration for the Accounts Payable (AP) process.

High-level Design

Rossum implements a two-way Coupa integration using the API. The integration pulls the necessary master data from Coupa and stores it in Rossum’s Master Data Hub. It then pushes the extracted, validated, and enriched data to Coupa, where the document is created.

Architecture Diagram

At a glance

• Documents (Invoices or Credit Notes) are imported into Rossum using one of the available methods: Email, manual upload, or API.

  • The most common and recommended method is Email, as it enables Rossum's communication features for the customer.

• Rossum extracts values from documents using its AI model according to the specified extraction schema (see the Coupa Integration Standard extraction schemas in the subpages).

• The extracted data is validated by business rules and enriched using master data previously replicated from Coupa.

• Finally, the data is mapped to Coupa fields and exported to create an Invoice or Credit Note in Coupa.

  • This process may occur automatically if the AI is confident and all validation rules are satisfied, or it may require human intervention in case of discrepancies.

  • The export result is visible in the Rossum UI, and any integration errors are displayed directly to the user.

Document Workflows

The standard integration supports the following AP document workflows:

• Non-PO (Draft): It is possible to implement custom account coding in Rossum to allow direct submission of non-PO documents. This functionality is not part of the standard integration.

• PO-backed (Submitted or Draft): Supports dynamic document submission logic.

Basic concepts

This section outlines the basic concepts used in the Rossum Coupa integration. These concepts are referenced throughout the documentation.

Extraction schema

The standard Rossum Coupa integration uses predefined document extraction schemas (see subpages for details). These schemas are designed based on experience with AP documents from various countries and are critical to the integration logic.

Rossum’s extraction schema is open and can be customized based on customer needs. Any schema modification must be analyzed, and appropriate adjustments to the integration logic must be designed and implemented.

Data Replication

A key concept of the integration is the use of master data from Coupa. Rossum replicates objects from Coupa via API, using them in logic and validation.

The CIB logic replicates and uses data from the following Coupa objects:

*There are by default no filters and the CIB logic replicates full data for the listed datasets. The fields (attributes) of the objects are limited to optimize the replication. All replications are differential (Rossum only pulls data created or updated since the last replication).

**All datasets are initially created with the suffix "_test", as testing environments are typically configured before integrating with production. The CIB is almost always deployed first against the Coupa TEST instance.

Dynamic Document Submitting in Coupa

You can read the difference between Drafting and Submitting of the document in Coupa in Drafting vs. submitting the documents in Coupa.

In the PO-backed workflow, documents may be either submitted or saved as drafts. Rossum evaluates submission conditions dynamically (e.g., tax codes, calculation checks). If no blockers are present, the document is submitted in Coupa. If submission fails, the document remains in draft status, and a warning is displayed in Rossum.

Line items extraction and export to Coupa

Coupa does require at least one line item to be present on the created document. However, it is not always the case that there would be line items data available after data extraction in Rossum. There are, in general, two reasons for that:

1. There is no tabular information on the document at all.

   1. For the Rossum AI to deliver the best accuracy and thus highest possible value certain annotation practices need to be followed. If there is no tabular information on the document Line Items table should be left empty and only available header level information should be extracted. User should not be creating a line from values scattered around the page just to satisfy needs of the target system.

2. Often the structure of the line items provided on the document is complex, the granularity is high and the information has no value for the process. In such case user might want to ignore the line items and only use the header level information from the document.

Because of the cases described above the Rossum integration in Coupa makes the line items optional in Rossum. User can choose if the lines will be extracted. In case the line items are not present in the extracted data Rossum makes additional set of fields visible on the header (Description, Tax Code Match PO Line Match, ….). These fields allow for populating all values that would normally be present on the line items. Rossum then creates a fallback line item for the Coupa purposes that is combination of the header level amounts and mentioned special fields.

There are notes about this mechanism on related fields in the schema reference.

Memorisation mechanism

Apart from the extraction of the data from the documents, Rossum’s functionality also adds value by matching different objects replicated from Coupa to enrich the data. Most of the objects are matched based on other values extracted from the document. There are cases when data present on the document do not uniquely identify the master data entry. For these cases users would have to always select a value from the offered prefiltered list.

Example:

• There is Supplier Name: “Sample Supplier DE” extracted from the document

• There are “Sample Supplier GMBH“ and “Sample Supplier Inc” entries in the Supplier master.

• None of the names in the master data match the name on the document. The fuzzy string matching mechanism will be used match the supplier.

• The system will return both suppliers (as their names are similar enough to the information on the document) and ask the user to select one.

• Without additional logic the user would be selecting the supplier on all documents.

To improve the efficiency and potentially automate the process Rossum implements a memorisation functionality. Whenever user selects a value from the list that is subject of this feature, Rossum remembers this selection for the context of the particular document. Next time the same context is detected (the same supplier name extracted in our example) Rossum populates the previously selected value automatically. If the previous selection was not correct user can still override the value populated by the recall functionality and select another value from the full list. The new value will also be used next time by the recall feature.

The recall mechanism is used in the Supplier and Customer matching logic in the CIB.

Duplicates handling

Duplicates handling in general serves as a safeguard to avoid double payments for the same goods or services and also to reduce double work in the process. Creation of duplicate invoices is blocked by Coupa itself so the more important part of the functionality in Rossum is to avoid wasting time processing of the documents that were already processed.

In the context of the Rossum workflow there are two types of duplicates:

• Duplicate documents in Rossum

  • Other documents in Rossum that are either exactly the same file (bitwise) or different files with the same extracted values.

• Duplicate documents in Coupa

  • In this case there are no duplicate documents in Rossum, however the same document already exists in Coupa.

Both scenarios and Rossum’s solutions are described in detail below. Documents detected in Rossum using any of the methods are marked and connected via duplicate relation.

Duplicate documents in Rossum

There are two main concepts of searching the duplicate documents in Rossum:

File based duplicate detection

The file based duplicates are searched based on the bitwise comparison of the file. For a document to be detected as duplicate exactly the same file has to be imported multiple times to Rossum. Even a small difference in the file causes duplicate not being detected.

For example if a supplier exports the same invoice to PDF twice from their source ERP system the files would not be detected as duplicates using this method even though they would look exactly the same when opened in editor. The reason is that the files would have different metadata (creation date) and they would not be identical on the bit level.

The second method described below provides a solution for such situations.

Extracted data based duplicate detection

This method uses the values extracted from the documents for the duplicates search. In the standard Coupa integration logic documents with the same Invoice Number and Supplier Export are considered duplicates.

Duplicate documents in Coupa

Apart from searching for duplicate documents that were previously processed in Rossum, it is beneficial to know if the document that is processed in Rossum for the first time already exists in Coupa.

Coupa has multiple ways for documents to be created, and in some cases, the document might already exist in Coupa when loaded to Rossum for the first time. In such a case, processing the document in Rossum might not be necessary anymore; the user could skip it and avoid double work.

Rossum brings a feature that provides the necessary context to the user so they can make a decision and eventually skip the processing of the document. Every time a new document is processed, the document is opened, or Invoice Number or supplier are modified, Rossum queries Coupa API to see if the document already exists there. If there is a document with the same Invoice Number for the same supplier in Coupa Rossum shows a warning and lists statuses of Coupa invoices (there can be more) in a visible field.

Tagging

Rossum uses Coupa tags as a way to indicate document-level information that is not related to any specific value in Coupa. Workflow exceptions are the typical use case for the tags. For example if there is a number of closed POs on the document, Rossum would treat the document as non-PO backed, draft it in Coupa and indicate the situation using po_closed tag.

The concept of tags can be enhanced based on customer needs.

There can also be logic (approvals, submission blockers) built based on tags in Coupa. Coupa also allows for document filtering based on tags and building views.

Standard tags used by the CIB are:

Business Logic Overview

This section summarizes the core business logic of the integration. For detailed specifications, refer to the Business Logic Specification page.

Payment Terms

Coupa does not have editable Due Date field by default (unless customer decides to add a custom field for this purpose. The Payment Due Date field in Coupa is always calculated based on the Payment Term selected on the invoice.

Rossum’s CIB follows standard Coupa configuration and uses information extracted from the document to match Payment Term replicated from Coupa (see details about the matching logic in the schema documentation child pages).

The Payment Term is matched based on either Due Date or extracted Payment Terms from which the days for payment are parsed. If there is no Payment Term matching the values on the document Rossum allows the user to manually select one and flags discrepancy between the document and master data.

There is also a check if the Payment Term on the document matches the Payment Term configured for the supplier, and a discrepancy is flagged if detected.

Coupa also offers an option to specify Payment Terms on the PO level. This information is not used in the CIB logic; however, it is a simple change of the configuration to utilize it.

Customer (Chart of Accounts) Identification

The extraction schema contains fields identifying the customer’s entity of the document. The extracted values are used to lookup a record in the account types (Chart of Accounts) replicated from Coupa. The matched account type is then stored in the Rossum annotation data. For the PO backed documents the Customer is taken from the first PO line of the matched PO. There is a check comparing the Customer matched based on the context of the document with the Customer from the PO. There is a warning message shown and automation is blocked in case of discrepancy. On the PO backed documents the PO Customer is always exported to Coupa. The resulting document created in Coupa has the Customer linked on the header level.

Supplier Identification

The standard schema contains fields identifying the supplier of the document. The extracted values are used to lookup a record supplier replicated from Coupa. The matched supplier is then stored in the Rossum annotation data. For the PO backed documents the Supplier is taken from the first PO line of the matched PO. There is a check comparing the Supplier matched based on the context of the document with the Supplier from the PO. There is a warning message shown and automation is blocked in case of discrepancy. On the PO backed documents the PO Supplier is always exported to Coupa. The resulting document created in Coupa has the Supplier linked on the header level.  The resulting document created in Coupa has the Supplier linked on the header level.

Bank Details

The CIB does not implement any specific logic for handling of the Bank Details (information about the bank accounts etc.). The reason is that maintenance of the Supplier Bank Details data in Coupa vary a lot between the customers.

Coupa by default works with the Remit-To Address object. There can be Remit-To addresses linked to the supplier. The Remit-To might serve as a banking connection in the US, however in the majority of other countries, specification of the address does not suffice for performing the payment.

Customers tend to use different address fields to store values like IBAN or Account Number or use the Remit-To Code field as a way to store the IBAN or other Bank Detail values.

Sometimes we see customers using the Supplier Information object (SIM record) for maintaining bank details data.

It is usually required to either select the bank detail record based on the data extracted from the document if there are multiple bank connections specified for the supplier (typically through the Remit-Tos) or to simply validate that the extracted data match the master data information.

Rossum is able to support these requirements using all variations of the data described above; however, the logic is implemented as part of the onboarding project.

VAT and Amounts

The standard schema has a number of fields that capture amounts and VAT-related information from the document both at the header and line item levels.

Rossum implements a set of validation checks to ensure reliable data extraction from documents of various structures. Users are warned, and automation is blocked in case discrepancies are detected between the extracted amounts.

There is also a set of calculations that ensure the data structure satisfies Coupa's requirements regardless of the document layout.

The CIB default schemas do not contain fields for extraction of the gross amounts (except Total Amount). It is for the benefit of the AI training and automation to keep the number of the extracted fields at minimum. From the experience the net amounts are (almost) always present on the documents.

Coupa Total calculation check

Coupa system does its own calculations using the data provided by the integration export (sums of lines, taxes, etc.). Because of the rounding and other issues on the documents the backward calculation performed by Coupa might not always yield the correct result matching the Total Amount present on the document. To avoid documents with incorrect amounts being created in Coupa Rossum implements the check that mimics the Coupa calculation logic and notifies the user about the discrepancies.

Purchase Order (PO) related logic

PO number present on the document

There are fields in the standard schema capturing PO number(s) from the documents covering the structure of the PO information seen on the various AP documents. Single PO number as well as multiple line specific PO numbers are supported both by the extraction schema and for the business logic.

There are multiple possible scenarios that can occur when the PO number is extracted from the document, and Rossum handles these situations in the following way:

1. PO does not exist in Coupa

   1. There is a warning message and automation is blocked.

2. PO is closed

   1. There is error message and document cannot be confirmed in Rossum.

3. PO is for a different Supplier or Customer

   1. There is a warning message and automation is blocked.

4. PO line is closed

   1. There is error message and document cannot be confirmed in Rossum.

PO number in Coupa, but not present on the document

Some customers might be working with the POs in Coupa, but the PO numbers are never communicated to the suppliers and thus never present on the incoming invoices. To support this scenario Rossum offers so called “Blanket PO“ selection. POs in status “issued“ for the supplier and entity matched on the document are offered for user selection. The selection is only available when there is no PO number extracted from the document.

Common logic

The extracted or selected PO number in combination with the line item description and the supplier part number to lookup the PO line in the master data replicated from Coupa.

There are multiple values from the matched PO line stored into the annotation data, used for validations and for the export of the data back to Coupa.

The PO backed invoices created in Coupa by the integration have the matched PO line linked.

If there is any PO number present on the document in Rossum the document is switched to the PO backed workflow and PO line match on all invoice lines is enforced before confirmation of the document. Combination of the PO backed and non PO backed invoice lines is not supported in the standard business logic.

Rossum in general prioritizes the information from the PO for purposes of the export to Coupa (Customer, Supplier)

Tax Coding logic

Rossum replicates tax codes from Coupa for purposes of the matching. Tax codes are not mandatory in Rossum, but they are part of the submission condition (see Dynamic Document Submitting in Coupa chapter above). There must be a tax coded linked to every line item in Coupa for the invoice to be submitted.

Rossum matches the tax code based on the country of the Tax Registration of the Customer (Chart of Accounts) matched on the invoice header and based on the tax percentage extracted or calculated on the invoice line.

If there is no Tax Registration matched or there are no tax codes available for the country and percentage Rossum offers all tax codes for the given percentage as a fallback.

Withholding Tax

There is no logic related to the Withholding Tax part of the CIB. It can however be added as a custom feature. We see a lot of variability in how customers are working with the withholding taxes (the withholding tax is also sometimes not mentioned on the document which requires a custom solution).

Account Coding related logic

ℹ️  The Account Coding is not part of the standard Coupa Integration logic, but can be implemented  as a custom feature if required.

Rossum in the standard logic supports replication of the Lookup Values from Coupa where the billing string segments are usually stored. The structure of the billing string is then reflected in the fields in Rossum schema. The segments of billing string are offered to the user for selection and the selection is “remembered“ for the particular supplier and invoice line description combination (see Recall mechanism concept above). Like this the items on the other invoices from the same supplier  with the same description can be coded automatically.

Please note that because of differences in the billing string structure configuration of this part of the logic has to be customized for each customer if required in Rossum workflow.

If all items on the document in Rossum are fully coded the document can be submitted in Coupa directly by Rossum.

Unit of Measure (UOM) and Invoice Line Type logic

Rossum follows the PO on the PO backed documents. Also for the case of UOM and Invoice Line Type the values are taken from the matched PO lines. If there is amount based PO line matched on the Invoice line in Rossum the invoice line in Coupa will also be created as amount based and Rossum will send the Item Net Total to Coupa as a price of the item and keep the quantity in the export empty.

If there is quantity based PO line Rossum will create quantity based invoice line in Coupa and it will send Unit Price as a price to Coupa along with the quantity. The UOM on the created invoice line will be the same as on the PO line.

For the non PO backed invoices the UOM is defaulted to EA (eaches). If there is UOM recognition logic required in Rossum it can be implemented, but it is usually very challenging because of the discrepancies between the supplier’s and customer’s understanding of the UOMs.

⚠️  It is strongly recommended to review the precision setting on the UOMs in Coupa. If there is 0 decimal precision on the UOM and the quantity extracted from the document is not whole number Coupa will cut the decimal part sent from Rossum which will lead to incorrect total amount of the invoice.

Credit Notes

The standard schema contains field Document Type and there are two types supported: Invoice and Credit Note. The integration creates the respective document type based on the value. When the Credit Note document type is detected by the AI, there are additional fields for capturing the original Invoice Number and Original Invoice Date made visible in the UI.

When there is a Credit Note document type selected Rossum automatically makes the necessary values negative or positive depending on the default value of the “Credit notes amounts“ field in the schema. This field is used to configure the behavior of Rossum.

Coupa can be configured to enforce either negative or positive amounts on the Credit Notes. Rossum standard integration is configured for the negatives, but the configuration can be changed in the mentioned “Credit notes amounts“ upon request.

There is additional logic related to the signs of the amounts on the credit notes. There can be scenarios when the document contains a mix of the positive and negative lines, and their sum is forming a negative amount total on the Credit Note. Rossum is capable of detecting and solving these scenarios to reach the correct Credit Note total with the correct preconfigured sign in Coupa.

As mentioned above Rossum uses dynamical submission of the documents to Coupa and evaluates if the document should be submitted or not. Document Type is part of the default submission condition in a way the Credit Notes are by default always drafted in Coupa. The reason is sensitivity of the credit notes.

Export pipeline

Rossum uses the Coupa API for the integration. The export of the confirmed document from Rossum uses 4 API calls:

• Create draft

• Attach the original file

• Attach the link back to the Rossum annotation

• Submit (conditional)

Before the first API call, Rossum maps the extracted, calculated, and enriched data to the Coupa API invoice payload.

The first API call creates a draft document in Coupa. The second call attaches the original file. The third call adds a link to the Rossum annotation to the invoice header in Coupa so users can easily navigate back to Rossum if needed. The last call is conditional and depends on the evaluation of the document data in Rossum. If Rossum evaluates that the document data is ready for submission to Coupa, the submission is performed via API.

After the last API call, Rossum evaluates the results of the API calls and sets the status of the document in Rossum. The high-level logic is as follows:

• If the creation of the draft (the first API call) fails, the document is moved to the Failed Export status in Rossum. In this case the document was not created in Coupa at all.

• If any of the subsequent API calls fail or when Coupa returns error or warning messages, the document in Rossum is moved to the Exported status (it was created in Coupa) and additional error/warning messages are listed in Rossum.

CIB Standard Extraction Schema (line level taxation)

CIB Standard Extraction Schema (header level taxation)

Drafting vs. submitting the documents in Coupa