This Version Created: September 26th, 2023
This Version Archived: March 17th, 2025
(MSA Archive)

Workflow Expectations

1. Setup of Test, Demo, and Production Sites

Nimbello will set up an internal Test Site with a standard configuration. Once Nimbello finishes related testing on the Test Site, an external site of https://demoClient.nimbello.com will be established. Upon Client sign-off on the Demo Site, the programming will be transferred to the production server and a new site will be created for Go Live – https:// Client.nimbello.com. The original Test and Demo Sites will continue to be used to develop any future changes before deploying them into the Production site.

2. Files from Client to Nimbello

Client will provide a single extract of each of the following files:

Vendor Master File
Purchase Order File
Receipts File
General Ledger File (1-2 files standard)
- Number of accounts sent to Nimbello should be limited to Accounts Payable accounts only (not AR or Balance Sheet) and no more than 200,000 rows.
ERP Import Confirmation report

Note: Import files should follow Nimbello’s Data Dictionary import format guidelines. If Client is not working with an integrations team, it is still the Client’s responsibility to ensure data files are presented in the appropriate format and contain the required data.

3. Files from Nimbello to Client

Nimbello will create the two (2) export files for import into the Client’s ERP along with an image of the approved invoices. These files will be imported into the ERP to create vouchers.

Note: If the Client is not working with an integrations team, it is the Client’s responsibility to ensure the data files are properly imported into the ERP for posting. Nimbello’s Data Dictionary file format will be provided by Nimbello with the posting data available.

4. File Imports from OCR

Invoice data extracted during the OCR process is detailed in Data Capture step 3.

5. PO Invoice Processing – Pairing

PO Pairing is the process of comparing each invoice line with a part number to the corresponding Purchase Order to find which lines from the PO are being billed on that invoice. The Workflow Rule set includes two (2) types.

The first type keeps all invoice line information and does the PO Line assignment based on the first rule found to have a unique pairing ability.

Single Line Pairing: Single invoice line to single PO line.
Unit Price Pairing: Unique pair between invoice and PO on a unit price.
Part Number Pairing: Can be up to two (2) PO part numbers. Unique pair between Invoice and PO on Part Number.
Quantity Pairing: Unique pair on Quantity Billed to Quantity Received between invoice and PO.

The second type does a replacement of the Invoice Line data with the Receiver data. These types of pairing can be turned off by request and also require appropriate data from the Client’s ERP in order to be used. Note: Appropriate data would include the PO being a Received PO and the Receiver data file containing the Received Dollar Amount and/or a unique Packing Slip.

Receipt Total Pairing: The invoice subtotal (all line items from an invoice that contain a part number) is compared to all receivers’ total received dollar amount. If there is a single receiver set that uniquely matches the subtotal of the invoice, the invoice lines (with part numbers) are replaced by the associated receiver lines and receiver quantities.
Packing Slip Number Receiver Pairing: Very similar to the above, the packing slip number on the invoice is picked up and compared to the packing slips on the PO. If there is a unique match, then the subtotals are compared and the invoice lines replaced by that Packing Slip/Receiver line information.

For invoices that have one (1) or more Invoice Lines with a Part Number, that cannot be paired to the PO, the invoice will go into a “Hold” status. There are three hold categories:

No Receipts – Pairing: All pairing was reviewed, but PO lacks receipts which prevents pairing.
Multiple Quantity Match Found: All pairing was reviewed, but multiple potential matches (based on quantity) exist preventing receipts from being paired appropriately.
PO Line Missing: All pairing was reviewed, but missing data prevents a match between the PO and Invoice.

6. PO Invoice Processing – Matching

After the invoice has been Paired, the next step is to determine if billing is accurate. That process puts the invoices through a series of checks. Below are the Workflow rules by category.

PO and Vendor Validity
- PO Invalid – PO Number on invoice cannot be found in the Client’s ERP import. This could be due to the PO being closed, not in a status sent to Nimbello or not a valid PO number.
- PO Vendor Mismatch – The PO is valid, but it does not belong to the Vendor picked up on the invoice based on the data received from the Client’s ERP.
- PO Line Missing – The PO Line had been assigned to the invoice, but that PO Line is no longer valid based on the data received from the Client’s ERP.
Pricing
- Price Variance (Debit and Credit) – The price on the invoice is outside of the tolerance allowed when compared to the PO. This is done line by line.
- Extended Amount Variance (Debit and Credit) – The Invoice Billed Quantity is multiplied by the PO Unit Price to get the calculated Extended Price. If the extended line amount is different from the allowed tolerance to the PO, then it is held. This is done line by line not on the invoice total.

Additional Charges: An initial classification is any invoice line that does not have a part number associated with it. The rule that the line follows is dependent upon keywords used in the description and the order in which they appear. See step 10 below
- Tax – wording includes “Tax”
- Freight – Wording includes “Shipping”, “Freight”, “Handling”, or “Delivery”
- Miscellaneous – Wording does NOT fall into one of the other two (2) categories
Receipts
- No Receipts – Insufficient receipts on the PO to cover the invoice line.
- Over Received – The receipts on the PO are more than are on the invoice and an exact match could not be identified.
  - If received cannot be auto-assigned, then the invoice goes on “Over Received” hold for that PO Line until a user assigns appropriate receivers.
Additional Rules
- Blanket PO
- PO Remaining Encumbrance
- PO Invoice Approval See step 9 below.

7. Two-way (Service) PO Invoice Routing

Two-way purchase orders requiring no receiving – thus skip all Receiving, Pairing, and Matching rules
POs needing approval or additional review. These can be either three-way or two-way PO’s which are directed to an individual user to approve after the regular Pairing and Matching Workflow is complete. The directed user has authority to approve the invoice regardless of invoice total.

8. Receiver Number Matching & export

A receiver is a unique identification number in the ERP that connects a receipt in the ERP with a PO and PO Line(s). In many ERP’s this is a unique rolling number that never repeats. Most ERP’s doing three-way matching also require this information be posted back to the ERP during invoice entry.

Receipt assignment is done in a multi-step process.

There is a unique match on packing slip between invoice and PO Billed Receipts
- Matched packing slip receipts are auto assigned to invoice lines
The total received equals the total billed
- All receipts for given PO Line are assigned to invoice line
A single receiver has a unique quantity match between the invoice and the PO Line Receipt
- That single receiver is assigned to the Invoice line
No unique identification can be made and the invoice goes on hold for manual assignment

Data Capture Expectations

Data capture processes occur throughout the day and are a three-step process.

Email / Paper receipt and classification
Audit and Batching
OCR Verification

1. Email and Paper

If contracted, clients may also receive a dedicated PO Box located in South Bend, IN for paper invoices. Paper mail is picked up once daily. It is sorted and OCR’d on the same day as receipt.

Each client has a dedicated email box to receive electronic invoices. Email is processed during US Eastern Time business hours.

Email received by client can be auto-forwarded from the client AP mailbox.

Considerations and Restrictions:

Emails received will be separated invoices from other mail.
- Other mail may include items such as statements, junk, and questions
- Statements and questions are forwarded back to the Client to sort and address
Vendor submissions should follow simple guidelines to improve the accuracy of the OCR technology.
- Invoices should be received as a single invoice per attachment
- File types are restricted to PDF, Microsoft Office extensions, and Images
  - Zip files are note supported
- Each invoice will be classified as a PO or Non-PO invoice along with the location (where applicable) of the Client site
- Emails received prior to 1 p.m. ET will be considered received on that day.
  - A limited number of Rush requests can be used on a monthly basis to expedite OCR processing – typically within 24 hours.

2. Audit and Batching

A separate Nimbello team will review the invoice files and ensure that they are accurately classified.

PDFs are gathered automatically and placed in queue for the Audit team
The Audit team confirms PO vs Non-PO as well as the Client’s location.
Once cleared, the Audit team prepares files for Batching into OCR.
If the Audit finds an error, the invoice is rejected to the Nimbello Admin team to review and advise

3. OCR Capture

The third team uses OCR capture to ensure accurate data retrieval from the invoice image. The accuracy of the OCR is dependent on the quality of the invoice. The following data fields are picked up by the OCR.

Note: An * on the fields below indicates that they are considered hard validations where the OCR will give an error flag if data is missing or not validated by proper measures.

PO Invoices

Vendor Name and Address are OCR’d and create a link to the *Vendor Number from the ERP active vendor list.
*Invoice Number
Invoice Date
*PO Number is validated against the active PO List from the ERP and against the vendor mapped
Packing Slip
Remit Zip (required in specific instances)
*Net (subtotal) Amount
Tax
Freight
*Total
Line-item details
- Part/Product number from Invoice
- Line Description
- *Line Quantity Shipped/Billed
- Unit of Measure
- *Line unit price
- *Line Extended Amount

Non-PO Invoices

Vendor Name and Address are OCR’d and create a link to the *Vendor Number from the ERP active vendor list.
*Invoice Number
Invoice Date
Approval Group if provided on the invoice
Remit Zip (required in specific instances)
*Net (subtotal) Amount
Tax
Freight
*Total

OCR confidence and accuracy

The OCR program rates each field and each invoice will an accuracy of data capture based on image quality and other specifications. If the OCR deems the pickup confidence to be at 100%, then the invoice will bypass Nimbello manual validation and go straight through to the Workflow.

If the OCR is under 100% confidence, a Nimbello user will validate the data as read by the OCR and make necessary corrections or approvals. OCR confidence is the accuracy of the data extraction from the invoice image on a per field basis. OCR confidence and accuracy do NOT relate to the accuracy of the invoice data against the PO.

4. Vendor-Specific Rules

Nimbello realizes that not all companies and not all vendors operate in the same way. As such, situations may arise where notation needs to be attached to a specific vendor for processing. We refer to these as Vendor Rules. There are many instances for Vendor Rules including how to format invoices without invoice numbers, PO formats, Part Number location, Packing Slip data, and Current vs Total Due. Below are the parameters to determine whether a standard process rule will be implemented or a specific vendor note can be added.

Standard Processing Rules

Standard rules govern 99% of vendor processing specifications. Below are the Nimbello standard operating rules for invoice OCR
- Vendor Identification done as a validation of Vendor Name + Remit to address.
  - DBA is allowed if provided as part of the Vendor File
  - If no remit is found on the invoice, then the address provided on invoice is used for validation
- If invoice number is not supplied by the vendor the following rule order is applied
  - Look for Account Number. Add account + invoice date (mmddyy) Invoice number length rules applied when invoice imported into Workflow
  - Look for Service Date
  - Use Invoice Date
  - Use Current Date
- PO Number is invalid on invoice to data from ERP.
  - PO number confirmed as provided on invoice as long as it is in the format of the Client PO
  - If not in the format of the Client PO, then the invoice is transferred to Non-PO processing
- Invoice has Current Due and Total Due.
  - Current Due is picked up as invoice total
- Vendor Paysite (multiple addresses to a single vendor record) Remit zip is taken from the invoice remittance section as is (5 or 5-4). Workflow assigns Paysite based on unique zip code match
- Part number mapping from PO Invoice lines will be mapped using the priority below:
  - Customer Part Number
  - Part Number / Product Number
  - Serial Number
  - Limited number of characters in the description* Determined by OCR operator based on best OCR results
  - X if unidentifiable
  - Blank if considered additional charge

OCR Validations

The following data from an invoice is confirmed against the Client’s ERP data provided or against the invoice data itself.
- Vendor Number – confirmed that vendor assigned is available and active. User reviewed address match during mapping
  - If no matching vendor is found, the invoice will be assigned to “Vendor Unknown" and sent for Client Verification in Workflow
- Purchase Order Number
  - PO Number is active
  - PO Number belongs to the vendor ID assigned to invoice
- Total Amount
  - The sum of extended amount (or Net) + Tax + Freight
- A Part Number validation can also be used to enhance the Workflow.
  - Available for Clients with a demonstrated high consistency between the vendor invoice and the purchase order. (Note: Use of this feature may result in an extra fee.)

Vendor-Specific Rules

Vendor-specific rules apply to vendors who consistently deviate from the expected standards of invoicing practices. The types of rules allowed are listed below. Note: Use of these rules will be limited to 10% of Active Vendors within a quarter.
- Invoice Number not labeled as Invoice Number. Some vendors may have a Bill Number, Customer Number, or other identification needed instead of Invoice Number outside of the account rule.
  - Field to be used must be clearly labeled on the invoice for mapping purposes.
- Service Date (or other similar wording) may need to be substituted for Invoice Date.
  - Field to be used must be clearly labeled on the invoice for mapping purposes.
- PO Number location not in a separated PO field. Some vendors put the PO Number in the line descriptions or at the footer of the invoice.
- Part Number may be labeled as one of many fields on an invoice. The desired Part Number should be in a continuous location on the invoice without interference from surrounding fields.
Vendor notes should not contain specifications (such as account to vendor verification, part verification where PO and invoice do not match, manual or unmarked sections of invoice that are required to be captured, etc.).

5. Payment Processing Services

Payment Processing Services are provided by Nimbello’s partner, Pay Clearly, and include the following:

ERP Data Services
1. Receive pay file from Customer’s Enterprise Resource Planning (“ERP”) system via secure file transfer protocol (“STP”)
2. Return payment confirmation file to Customer’s ERP via STP
Payment Disbursements using the following available methods:
1. Virtual Card or “vCard”
2. Automated Clearing House or “ACH”
3. Enhanced ACH (an ACH payment where a fee or discount is charged to merchant or supplier for acceptance of such payments)
4. Electronic check or “eCheck” (payments made online by entering Customer’s banking information )
5. Printed check
Card Payment Automation
1. Email Payments: Pay Clearly automatically creates and delivers a single use card with the relevant remittance data required by the supplier
2. Portal Automation: for suppliers that require payments processed via a web-based portal. Pay Clearly automates this process, allowing for accurate payment execution and unlimited scalability
3. Fax Payments: Pay Clearly can automate the delivery of fax payments, and can support using a customized form provided by the supplier
4. Concierge Payments: Where a manual touchpoint is required, Pay Clearly’s concierge payments team will contract the supplier directly to complete the payment
Supplier Enablement
1. Supplier Letter Campaign
2. Calling campaign
Payments Workflow (in Nimbello portal)
1. Link payment information to invoice data
2. Invoice Search - Search by payment status, payment number, payment date
3. Invoice details page - view for payment date, payment type, payment number, and amount paid
Payment Approvals Page (in Nimbello portal, configured by customer to be active or inactive)
1. Search payments based on approval status, vendor, etc.
2. Update approval status (approved, declined, etc.)
3. Configured based on dollar values and/or authority levels

Product Capability Documentation