Nimbello Product Capability Documentation

This Version Created: March 17, 2025
(MSA Archive)

Article 1. Invoice Data Capture

Section 1.01 Nimbello OCR SaaS

With Nimbello OCR SaaS clients have access to Intelligent OCR Software to manage invoice receipts through data verification.

The Nimbello OCR SaaS software includes:

Automated collection of attachments from documents received in the Nimbello Client AP Inbox assigned during implementation.
Classification of documents
Separation of invoices into PO and non-PO
Automated creation Batches ready for Data Capture
Data Capture engine using machine learning to improve accuracy
Data Verification function for Processors to validate accuracy of data captured, adjust “train” the Data Capture engine for improved accuracy going forward.
Integration of invoice data and images to Nimbello Workflow SaaS
Implementation and configuration services
AP Processor Training

Section 1.02 Nimbello Managed Services

With Managed Services, the Nimbello Operations Team performs a three-step process to accurately capture invoice data and resolve exceptions.

(a) Step 1 - Email and Paper; Receiving and Classification

Each client is assigned a dedicated Nimbello email AP Inbox to receive electronic invoices. This AP Inbox is managed by the Nimbello Operations Team during US Eastern Time business hours. Emails received by the client can be auto forwarded to the client’s Nimbello AP mailbox. Email processing includes:

Separation of invoices from other document types
Other document types 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 not 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.
If contracted, clients may receive a dedicated PO Box located in South Bend, IN for paper invoices. Paper mail is picked up once daily. It is sorted and processed on the same day as received.

(b) Step 2 Audit and Batching

The Audit Operations Team reviews documents to confirm the accuracy of classification.

The Audit team confirms PO vs Non-PO classification as well as the Client’s location.
Confirmed invoices are batched for OCR processing
Unconfirmed documents are rejected where the Nimbello Operations Admin team for review and resolution.

(c) Step 3 Data Capture

The Nimbello Operations Team uses Intelligent OCR software to capture data items from invoice documents, verify accuracy, identify exceptions and advise on resolutions.

(i) Data Captured from PO Invoices

Vendor Name and Address are captured using OCR and validated Client’s ERP Vendor as Active.
The Vendor Name, Address and Number from the Vendor ERP populate the respective invoice data fields
Invoice Number
Invoice Date
PO Number
PO numbers are validated against the Open PO List from the ERP and against the Vendor information from the ERP
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

(ii) Data Captured from Non-PO Invoices

Vendor Name and Address are captured using OCR and validated Client’s ERP Vendor as Active.
The Vendor Name, Address and Number from the Vendor ERP populate the respective invoice data fields
.*Invoice Number
Invoice Date
Approval Group if provided on the invoice
Remit Zip (required in specific instances)
*Net (subtotal) Amount
Tax
Freight
*Total

Fields marked with an * are considered hard validations that will need to be resolved before successfully completing the Data Capture step.

(d) Step 4. OCR Validation

The OCR software rates each field based on the confidence in how accurately the software captured the data from the invoice image. (OCR confidence and accuracy are not related to the accuracy of the invoice data against the PO.). The Confidence rating is used to determine when the Nimbello Operations Team performs manual validation and correction. If the OCR deems the confidence to be at 100%, then the invoice will bypass Nimbello Operation’s Team manual validation and go straight through to the Workflow. If the OCR is under 100% confidence, a Nimbello Operations Team will validate the data as read by the OCR and manually make necessary corrections or approvals using a set of rules applied to specific vendors.

(i) Standard Vendor Processing Rules

Standard rules govern 99% of vendor processing specifications. Below are the Nimbello standard operating rules.

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 associated with 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

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.

(ii) Vendor Specific Rules

Vendor-specific rules apply to vendors who consistently deviate from the expected standards of invoicing practices. The 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.

Article II. Nimbello Workflow SaaS

Section 2.01 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 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.

Section 2.02 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.

Section 2.03 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 valid AP transactions.

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.

Section 2.04 File Imports from Invoice Data Capture

Invoice data extracted during the OCR process is detailed in section Data Capture and Validation.

Section 2.05 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.

Section 2.06 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.

(a) 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.

(b) 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

(c) 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

Section 2.07 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.

Section 2.08 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

Article III. Payment Processing Services

Nimbello has partnered with PayClearly to provide the Payment Processing Service. PayClearly disburses payments, described later in this document.

Section 3.01 Data Services

Nimbello provides data integration connecting the Client’s ERP, PayClearly and Nimbello via Secure File Transfer Protocol (SFTP).
Client Pay File from the Client’s ERP to Nimbello
Payment data from Nimbello to Client’s ERP
Data sharing between Nimbello and PayClearly to facilitate payment execution and updating Client’s ERP.

Section 3.02 Payment Disbursements

PayClearly will disburse payments using the following available methods:

Virtual Card or “vCard”
Automated Clearing House or “ACH”
Enhanced ACH (an ACH payment where a fee or discount is charged to merchant or supplier for acceptance of such payments)
Electronic check or “eCheck” (payments made online by entering Customer’s banking information)
Printed check

Section 3.03 Card Payment Automation

Email Payments: Pay Clearly automatically creates and delivers a single use card with the relevant remittance data required by the supplier
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
Fax Payments: Pay Clearly can automate the delivery of fax payments, and can support using a customized form provided by the supplier
Concierge Payments: Where a manual touch-point is required, Pay Clearly’s concierge payments team will contact the supplier directly to complete the payment

Section 3.04 Supplier Enablement

PayClearly will conduct ongoing and continuous supplier enrollment processes, which may include, subject to Client’s approval, Real-Time Enrollment (RTE). RTE is the preferred enrollment method.

As part of the RTE enrollment process, the PayClearly enrollment team will proactively engage suppliers using current payment and invoice data, offering the option to convert check payments to Virtual Card or ACH.

In addition to RTE, supplementary enrollment strategies may be implemented, including but not limited to, targeted mail campaigns and informational enclosures within check payments.

Section 3.05 Payment Data Available in Nimbello portal

From the Nimbello portal:

Payment information will be linked to the invoice data
Perform Invoice Search by payment status, payment number, payment date
The Invoice Details page will include payment date, payment type, payment number and amount paid.