TradeShift Introduces CloudScan — A Shift in E-Invoicing Philosophy as Much as Technology (Part 1)
Earlier this week, TradeShift introduced CloudScan, a new cloud-based OCR service that at first might sound like the countless other scanning services available from competing e-invoice providers and network operators. But CloudScan is different in more than one way. Perhaps most important, CloudScan does not just provide a scanning service that captures different document formats delivered electronically (e.g., a picture of an invoice taken from a mobile phone) or a PDF document sent via email. Yes, it does this. And judging from the demonstration we saw and the discussion we had with TradeShift, its level of OCR accuracy seems accurate enough for most purposes (not leading, but sufficient).
This is secondary, however. What matters more is that CloudScan is fundamentally different from other OCR-based supplier connectivity approaches for e-invoicing document exchange in that it is really a stealth means of kicking off a continuous on-boarding and supplier management process that leverages supplier self-service to reduce AP and procurement hands-on involvement. As TradeShift positions CloudScan, the solution uses the TradeShift network to “ensure that all handling of exceptions happens on the supplier side, which means no work for the buyer.” This certainly sounds like a good approach in theory. The good news is that in practice, the claim is largely true, as you’ll see in a minute.
The first step to using CloudScan is to request your suppliers to send invoices as PDFs or pictures to a specific email address provided by TradeShift. Next, CloudScan, like other scanning and virtual printer solutions converts the received content into an XML format. At this point in time, for new suppliers, a TradeShift account is created. But as you might guess, an invoice alone does not provide enough detail (in most cases) to create a complete supplier profile. Contact information, banking instructions, detailed terms, etc. might be missing from a typical invoice. For this reason, once the “scanned” invoice is in the system and the supplier registration process has begun, the next step is a process requesting more information from the supplier, plus validation and corrections.
At this point, TradeShift requires that suppliers connect to the TradeShift portal to provide their stamp of approval on the invoice submitted and the accuracy of the capture. When they login to this portal, they are greeted with an interface that is easy to walk up to. The portal would look familiar for anyone who has used Gmail, Facebook, LinkedIn or a similar easy-to-use web-based application. It appears virtually idiot proof, providing basic navigation on the left (e.g., mail, contacts, tasks, notes) and a second navigation/task bar at the top (e.g. invoice/scanned archive, “move” files, delete, label).
As they log in, TradeShift even explains why suppliers need to provide validation information as part of the process, and that in “99% of cases, validating an invoice takes less than a minute.” Once in the validation area of the portal itself, the supplier screen is split between the information captured from the OCR service (on top), e.g., the PDF invoice, and a “new” invoice created from that data on the bottom.
As suppliers click or scroll through fields on the top of the screen, they are also highlighted on the bottom (e.g., company name, address, registration number). TradeShift also calls out to suppliers with highlighted arrows and starred/exclamation point fields information that is missing or required. As the supplier information is added to the invoice itself as part of the validation process (e.g., registration number) it is added to the supplier’s master profile data at the same time in TradeShift’s system. If you labeled this as a “stealth onboarding” process, you would not be wrong in your assertion. At this stage, suppliers can also opt to sign up directly to TradeShift through a data collection and invoice submission portal, should they wish to avoid validation steps in the future.
After all the information is validated and captured from the supplier, it is then submitted as XML data into the buyer’s TradeShift platform (or wherever they want to consume the information) for review and their own involvement (e.g., manual final/validation, matching). And, owing to the network approach of TradeShift, suppliers are prompted before logging off to consider using the system for their own invoice receiving and creation for their suppliers and customers as well. But the real power of CloudScan for AP and procurement organizations — at least initially — is not about creating multi-tier participation and visibility. The simple genius is about pushing validation for a relatively highly error-prone process (OCR) relative to other types of invoice submission back on to the supplier and at the same time, using the validation request to collect additional details.
It’s supplier onboarding without the pain of onboarding. How novel!
Stay tuned as our analysis and observations on TradeShift CloudScan continues.