Like any software-based technology service, CloudTrade continually looks to improve its technical platform, increase scalability and support technical stability as the company continues to grow in customer numbers and document volumes. CloudTrade CTO Richard Develyn outlines in this blog post how we are currently rolling out a new technical architecture based around containerisation.
Containerisation and cloud computing in general is definitely the way of the future. The technology and adoption of these systems is proceeding apace. Given our position in the market as a service provider experiencing high growth, our move to containerisation was essential, and we are happily now well on the way to completing the implementation of containers for the whole of our analytical data-capture service and for the whole of our customer base.
For the last two years CloudTrade has been in the process of re-deploying its core analytical data extraction service onto this highly scalable, cutting edge, infrastructure technology.
As of February 2021, most of the processing that delivers our core service has been teased apart and deployed within individual Microsoft Azure containers. This milestone marks the end of the second stage of our implementation strategy, and consequently the beginning of the migration of our existing customer base onto this second stage.
During the first stage we implemented containerisation for our core rules-processing engines and migrated our customer base accordingly. At the end of the third stage, everything will be running in containers. First-stage implementation, therefore, was all about moving the most processor intensive parts of our service across. Second stage has ensured that all of our time-critical processes are also across. The third stage will be there to mop up the rest.
The purpose of containerisation is to take a service or application and split it into little bite-sized pieces each of which can be individually deployed and scaled up or down on demand. These “pieces”, known as containers, are managed using a container eco-system such as “Docker”. Docker was the first open-source implementation of such as a system and has now gained wide-spread use in industry today. Docker is also the system that we use in CloudTrade.
This container eco-system also includes within it a container orchestration tool that monitors various performance metrics associated with the individual containers and queues of messages which run between them and decides, via configurable rules, whether more of them should be spun up or whether some of them should be closed down. This key component allows a containerised system to not only make best use of its resources but also to perform optimally in the face of bursts in its processing demands, such as we regularly encounter in CloudTrade when document senders do nothing at all for days and then send us a whole pile of documents expecting them to be processed at once.
The most popular container orchestration tool is called Kubernetes. This tool originally descended from a project developed internally at Google and is now one of the most successful tools of its kind. Kubernetes is also the orchestration tool that we use in CloudTrade.
A containerised application or service has the additional benefit of being operating-system agnostic. This means that containers that might be running on Microsoft Azure today could be deployed on AWS or a Linux-based system tomorrow. This allows a service provider to not only make best use of the operating system resources that they have with their cloud system of choice but also to consider moving part or all of their service onto other operating systems if that would result in better performance or lower costs. Currently, we deploy on Microsoft Azure, but we are keeping an eye on other cloud system providers.
In this blog post, CTO Richard Develyn unpicks the confusion surrounding the significance of the various levels of application interfacing. He outlines how APIs and data-stream format are not as complex an issue as many people feel them to be. He argues that it is, rather, sufficiency and process in interfacing that are of much greater importance when ensuring that applications can successfully communicate with each other.
We probably spend more time worrying about the things that we shouldn’t and not worrying about the things that we should with regards to interfacing than we do about anything else.
Interfacing is a many-layered thing. Some of the layers are hard and some are easy. Unfortunately, all of the layers are called “interfacing” and that’s where the confusion appears, because we want to make sure that we have a clear answer in our heads about whether interfacing is easy or hard and the fact is that it’s both easy and hard depending on how you’re looking at it.
We therefore need to prise apart these layers in order to get a better understanding of it, in particular with respect to the challenges that we face here at CloudTrade when we try to connect our analytical capture service to other applications and systems.
This is the least important part of the interfacing challenge and yet it is often the one that gets the most talked about. Although API stands for Application Programming Interface, in actuality it is interfacing at the simplest possible level in inter-application communication. APIs provide the mechanism for applications A and B to exchange data, but that’s as far as it goes – i.e. APIs make no guarantee on whether A and B will actually speak the same language or be able to make sense of what each of them is doing.
The reason APIs get a lot of prevalence is because there are a great many As and Bs in this world and therefore many APIs for connecting them. Sometimes these APIs are standardised, such as SFTP, HTTPS. Sometimes they’re not, which can give rise to interesting API wars, where the manufacturer of application A will publish an API for connecting with it, as will the manufacturer of application B; the APIs will not be compatible and neither side will want to shift to accommodate the other. Outside of such chest-beating, however, companies such as ours will always try to work with any API, and will happily implement a bespoke API as long as it is documented and the customer will commit to help with the testing. It is typically 1 – 2 weeks of development work for a completely new API.
The bottom line is – don’t worry about APIs. If we don’t support your API but we’re definitely going to be doing business together then we’ll sort that problem out even if it involves a small amount of new development.
If the API sorts out the wire that connects us, “format” is where we agree on what the data that we exchange actually means. Typically, this is done with XML file / data-stream formats, though all sorts of other formats are possible too. XML stands for Extensible Markup Language, and what it basically says with the word “markup” is that it defines how meaning is attributed to data. For example, in the XML sequence:
the data item “Richard” is given the meaning “name”. If I extend the example like this:
Then the meaning of “Richard” is further qualified as being a customer’s first name.
XML file formats tend to be more standardised, though variations in the use of these standards, as well as extensions to the standards and the presence of completely bespoke file formats also do exist. Generally speaking, however, people don’t tend to worry so much about getting this sort of interfacing sorted out as much as they do about APIs; I guess it feels easier, though it can actually be just as awkward.
At the end of the day, however, the bottom line for format interfacing is the same as with APIs. If we’re not already using a common interface, we might need to do some additional configuration work at our end to sort that out, but it’s all quite possible.
This is where things can get a bit thorny. If we can’t provide you with everything that you need, or vice versa, then we’re not going to be able to work together.
This can be so “drop dead” that if we have any sort of doubt whatsoever then we need to bottom it out before we go any further. The difficulty is that sometimes these problems of insufficiency are down in the detail, the most classic one for us being if your finance system cannot process invoices without line-level, purchase-order line numbers, and your suppliers don’t provide them in their invoices, and we have no other place that we can get them from.
Sometimes the problem is not so “drop dead”, but might imply that there is some significant work on our part that is needed for us to do in order to get that missing information, or possibly even on your part to adjust your target system so that it doesn’t need that information any more. Either way, this interfacing layer is an important one, so the bottom line here is that we need to make sure early on that we don’t have an unresolvable issue with sufficiency.
Is our application doing what your application needs it to do? It must be, otherwise we probably wouldn’t be talking to each other in the first place. You would have thought, anyway.
In the Accounts Payable and Accounts Receivable application space, where we have been operating for many years, this isn’t really a question in anybody’s minds, but in some of the new areas that we are moving into, such as Fraud Detection and RPA data feeds, some sort of sanity check on expectations should take place.
For example, if we detect fraud, are you expecting us to call the police? Probably not, but the bottom line for this one is that we need to make sure that we have a common understanding of the functionality that we are providing and you are expecting.
Finally, the one that seems to cause us more problems than any other.
Applications have Use Cases – a term borrowed from Software Analysis and Design but now used to catalogue all of the different ways that an application can be used. When applications join together, these Use Cases have to interface with each other in order to satisfy the over-all Use Cases of the application suite. If you’re not careful to join these Use Cases together properly then anomalies and holes can occur into which transactions can fall never to be seen again.
This requires careful analysis of how each Use Case is going to progress through the whole system. The problematic ones tend to be the ones where an error occurs somewhere in the process. If it happens in the “feeder” application, which is typically ours here at CloudTrade, then the “receiver” application must be able to receive this error from us (however it wants) and do something sensible with it. If the error occurs in the “receiver” application, perhaps as a result of something that we did but had no idea was wrong when we fed the transaction through, then again the “receiver” application has to do something sensible with that. The two things that cannot happen are for the “feeder” application to be left holding the baby with nowhere to put it, or for the “receiver” application to drop the baby into some black hole which is either literally a black hole or one that nobody ever bothers looking into.
The bottom line for process interfacing is that this has to be sorted out before we do business, otherwise we’re likely to set something up which will ultimately fail.
We probably wouldn’t even be discussing working together if we didn’t have our application-level interfacing needs sorted out, but it’s worth just touching base if we’re not in the world of Accounts Payable or Accounts Receivable. After that we should take the time to ensure we have no fundamental problems with either sufficiency-level or process-level interfacing before we even begin to get worried about APIs or data formats. As for the latter two, although we’re very unlikely to develop bespoke API or data formats “on spec”, because there’s just so many of them, they aren’t a barrier to business as long as we agree development costs, and we can generally develop or modify what we have during the time that we take to deploy a new system.
Interfacing is a many-layered problem. The important thing as we consider working together is to make sure that we worry about process and sufficiency, rather than API or data format, as the former are the ones that can cause real issues, whereas the latter are ones we can sort out with a little bit of time and effort.
What is a template in the world of CloudTrade automated data capture? In this blog post, Richard Develyn, CloudTrade CTO, explains how a template is something much more flexible than you might imagine. Secondly, he describes how adaptable templates form the core strength of the CloudTrade solution.
If you check out the definition for the word “template” in any dictionary, online or otherwise, the first answer that you’re likely to encounter will probably read something like this:
“A preset, shaped piece of rigid material used as a pattern for processes such as cutting out, shaping, or drilling.”
If someone then tells you about a company that uses templates as a means of reading information from a document then you will probably imagine that, in some sort of IT-equivalent way, they cover a document with a piece of metal which (a), has square holes cut into it to allow parts of the document to be “extracted” from below and, (b), has words scratched into it somehow which have to line up exactly with the words that are written underneath.
The problem with mental images like this is that they’re (a) easy to imagine, (b) easy to understand, (c) easy to remember and (d), in the majority of cases, quite wrong. Go beyond the first dictionary definition for “template” and you will discover that in the field of computing a template generally means:
“A preset format for a document or file.”
Investigate that word “format” further and you will find terms like “arrangements” and “patterns” suggesting a much more fluid interpretation than the image of piece of metal with holes in it might suggest.
Why a set of rules does not need to be rigid
Ultimately a template is just a set of rules. The “metal with holes in it” example is only a very specific, and rigid, case of what those rules could be – e.g. “this piece of writing must occur here on the page” or” that bit of information that we need to extract has to occur there on the page”.
A set of rules and a template are really just the same thing, however, unfortunately, it’s far too easy to think “rigid” when you read “template” and so jump to the erroneous conclusion that a system which works using a set of rules must be working in a very rigid way.
This sort of semantic mix up is a nuisance, particularly for us. It has caused us to stop using the word “template” when explaining how CloudTrade works. Our data-extraction solution is indeed based on writing natural-language style rules. Yes, you could call that a template. No, this is not the equivalent of using a rectangular piece of metal with holes in it stuck over the top of a piece of paper!
If we’re going to be stuck with this mental image however (mental images like this being so hard to shift) then we need to imagine that our templates are not made from a rigid material like metal but rather are created from some sort of stretchy flexible substance that automatically aligns itself to the document that we’re trying to examine – a bit like intelligent rubber. Our stretchy-templates may well have holes in them which allow us to read the data that we’re looking for, but these holes can grow and shrink and move around. Our stretchy-templates might stipulate data which has to be present in the document “below” them, but that data can have different values and locations depending on whatever else the document has in it.
Flexibility is key to the CloudTrade solution
This is what gives our system its power. We program our stretchy-templates to deform themselves in the necessary and particular ways which match the variations in the document that we’re trying to examine. It doesn’t matter how the information on a document moves around, we can set up our stretchy-templates to accommodate it and always pick up the right data wherever it happens to be.
Much though we’d like to, it’s difficult to avoid using the word “template” when we describe what we do. Many people in our industry use it. Unfortunately, the temptation is to think that “rules system” equals “template” and that “template” equals “rigid piece of metal with a load of holes cut into it”. If you find yourself thinking rather along these lines, then, at least try to imagine that our templates are rubbery and stretchy rather than rigid and metallic. It might be an odd sort of mental image to carry in your head, but at least it’s much closer to the truth than the alternative.
In this blog post, Richard Develyn CTO, explores what true service looks like with a software solution and if the SaaS model is truly all it’s cracked up to be.
If you went into a high-class restaurant and ordered yourself a meal, you wouldn’t expect to be directed into the kitchen and presented with the recipe and ingredients and then told to get on with the cooking, even in these COVID-troubled times.
This would, however, be the culinary equivalent of Software as a Service (SaaS).
Take away the recipe and ingredients and you would have Platform as a Service (PaaS). If you were also told that you were in charge of maintaining the cooker and keeping the fridge stocked up, you would now be in the realms of Infrastructure as a Service (IaaS).
So, what do you call it when all that you want is to have the meal of your choice presented to you, on a plate, with knives and forks, and simply be allowed to get on and eat it?
There doesn’t seem to be anything in the IT “as a Service” world to describe such a thing. Personally, I would call it “Service as a Service”. Never mind how it gets to you. Never mind who does the cooking, or where they get the recipe, or what make of water bath they used when they produced that sous-vide steak that still seems to be well done on the outside but raw on the inside. What you want is to satiate your hunger, preferably with something of high quality, and you have neither the time, nor expertise nor inclination to satisfy that requirement yourself.
A big problem for vendors with Service as a Service is that if, say, the steak was undercooked, and the customer was unhappy with it, then the customer would be perfectly entitled to send it back or get their money back or get another steak or refuse to pay. Vendors of Software as a Service are free of this sort of problem because, following the restaurant example above, the customers are basically responsible for cooking the thing themselves and it’s up to them to get it right.
SaaS, therefore, favours the vendor, whilst Service as a Service favours the customer.
Unfortunately, SaaS vendors all too frequently claim that they deliver their solution as a service. This is misleading. What SaaS vendors are actually doing is delivering a toolset for their solution as a service, not the actual solution. The correct implementation of that toolset is left entirely to the customer. SaaS vendors can’t even guarantee that their toolset will suit the customers’ needs. In a sense, they can’t, because the success of that solution will be dependent on the customer using their toolset in the right way, and they have no control over that. Sure, if the software being provided “as a service” is easy to use then everyone is going to be pretty much on safe ground, but if it’s complicated, or requires skill or expertise, then all bets are off.
CloudTrade delivers Service as a Service. Customers don’t operate our software – we do. We take responsibility for it being fit for purpose and for making sure that it works well to our customers’ requirements. Our customers don’t have to worry about the difficulties or idiosyncrasies of extracting data from their documents. We do all that. Furthermore, we do it for a fixed price, regardless of how complicated or weird any of these documents might turn out to be.
Sometimes you don’t mind cooking the food in a restaurant yourself. Fondues are like that, but then they’re not exactly difficult to do – prod a piece of bread with a fork, stick it in the bubbling cheese, swirl it around a little bit and then eat it with a nice glass of wine. Identifying meaningful data from human-readable documents is not the data-extraction equivalent of a fondue, I’m afraid, at least not in the general sense. Project Grandalf (and perhaps we should rename it Project Fondue) is where we’re making inroads in this direction for simpler documents, but our main service remains one where the customers receive their dinners ready-to-eat, and where we look after the kitchen. CloudTrade is, indeed, a true Service as a Service provider.
Interested to learn more?
Download our flyer to find out more on the services that we offer here at CloudTrade.
https://i1.wp.com/www.cloud-trade.com/wp-content/uploads/2021/02/AdobeStock_238462607.jpeg?fit=800%2C515&ssl=1515800Richard Develyn/wp-content/uploads/2019/04/CloudTradeLOGO.pngRichard Develyn2021-02-03 18:00:432021-02-03 19:34:47Service as a Service
Is Robotic Processing Automation (RPA) science fiction or science fact? Does it have a part to play in the CloudTrade story? In this blog post, the third in his trilogy explaining the CloudTrade data-capture solution, Richard Develyn, CloudTrade CTO and sci-fi film enthusiast, lays bare the limitations of RPA, exposing the very real challenges associated with coverage, complexity and scope.
In Fritz Lang’s 1927 film, Metropolis, a worker stands in front of a man-sized clock moving the clock’s hands to point to different light bulbs arranged outside the edge of the clock’s rim. Every few seconds, two of the light bulbs light up, and it is clearly the worker’s job to move the hands to point to those particular light bulbs rather than to any of the others.
This is what I call a Robotic Process.
As the film progresses, however, it becomes clear that the worker’s task involves more than just looking out for lit light bulbs and moving the clock’s hands accordingly. Arranged on the same panel as the clock are several gauges and dials which are somehow affected by what the man is doing, and which appear to have safety thresholds triggered if something starts to go wrong. Judging by the man’s reaction as he becomes tired and the needles start to climb alarmingly towards their red zones, it is also his job to keep these dials under control, and there appear to be some very large levers to the side which we assume he has to use “in case of emergency”.
Fritz Lang makes an important point about automation in these scenes, a point which has pervaded our view of science-fiction dystopian futures ever since. Making humans perform robotic processes may be dehumanising but replacing humans with robots runs the risk of a catastrophe occurring if those supposedly robotic processes start to behave in unexpected ways.
This problem is not helped by RPA because RPA “bots” are a particularly dumb sort of robot. RPA bots only achieve their advantages over other forms of IT, such as programming, because they learn what to do by watching their human counterparts and then replicating their, supposedly, dumb human behaviour.
Stick an RPA bot in front of the Metropolis clock-worker, therefore, and that bot is going to encounter three pretty fundamental problems.
The first is that, even in normal operation, the number of possible combinations for two lights around the clock is 2,116 (there are 46 lights around the clock, 43 labelled 1-43 plus three other ones labelled I, II and III), and some of these combinations might occur very rarely. An RPA bot cannot be programmed (strictly speaking, but see later) with the instruction “move the clock’s hands to the lit light bulbs”, all it can do is watch the human clock-worker and copy, dumbly, what the human worker does. The bot’s learned knowledge base, therefore, will consist of a series of instructions along the lines of: “when bulbs 12 and 37 are lit, and no others, move the hands of the clock to positions 12 and 37”. If this particular combination does not happen when it is being trained, then that bot is not going to know what to do should that combination subsequently happen in “live”.
I suppose you could classify this problem as insufficiency in training, but the issue is deeper than that. Watching an operator work on a machine for some fixed period of time does not constitute a very sensible learning plan. What if half the bulbs only come on in winter and you happened to have trained your bot in the summer? This problem should really be termed one of Coverage, i.e. knowing what the span of possibilities is, against which you can measure sufficiency. If you have no handle on Coverage, then you have no idea how well you’ve managed to train your bot.
The second problem happens when there’s some sort of underlying complexity to the robotic process which the bot cannot perceive, such as, perhaps, if the order in which the operator moves the hands depends on one of the gauges to the side which the operator is keeping an eye on. The bot can see what the operator sees and note what the operator does as a result, but it has no insight into how the operator is thinking.
This problem should be termed the one of Complexity, which is a recognised and insidious one in the world of RPA. Operations that appear to be simple are later discovered to have more complexity about them than at first thought. The situation becomes worse if it turns out that the operators themselves have some sort of internal state which the bot needs to discover, such as that carried in the instruction: “if the dial moves into the red zone three times in an hour then reverse what you’re doing with the hands”. If the operators are exercising judgement or skill in what they’re doing then the problem gets worse again, as in, for example: “ensure this gauge lies between those two safety lines; if it drops below the lower one then move the hands faster, if it rises above the higher one then move the hands slower”.
Of course, you can increase the complexity of the bot itself to pick up on these things and try to learn them, but it doesn’t take long before you start wondering whether you shouldn’t just have written a program in the first place.
The third problem occurs if, say, one of the bulbs blows, or the handles start moving by themselves unexpectedly. The human operator will likely do something sensible like change the light bulb or let go of the hands, even if they haven’t previously been trained how to do so. Systems created to be operated by humans are built on the basis that humans, not bots, are going to be sitting in front of them. Sometimes these systems will have all of their behaviours documented and sometimes not, but always there will be the assumption that a reasonable human being, with an organic brain in his or her head, will be able to react sensibly to whatever might happen. Bots aren’t people, I’m afraid, and it’s no good pretending. Bots can’t think “outside the bot”, which is why computer interfaces are built in quite a different way to the interfaces that are built for humans.
And then there’s the issue of change control. If Metropolis Central were to decide that they were going to enhance their clock-machines so that every now and then a little message would pop up saying “stand away” followed by the clock’s hands sizzling with electricity, then there’ll be no doubt in the minds of their engineers that the clock-operators will figure out, pretty quickly, what they need to do. The bots, however, will repeatedly get frazzled.
This final problem is the problem of Scope. A poor dumb RPA bot isn’t going to know what to do when anything happens which is outside of the inputs and outputs that it was told about, even once it gets past the problem of Coverage. It can’t read the message “stand away” if it’s never encountered it before, which of course will definitely be the case if the message couldn’t happen when the bot was being trained because Metropolis Central subsequently changed the behaviour without troubling to inform the RPA bot vendors.
The only way to solve any of these problems is to program the bots up using some sort of scripting or programming language (and a proper change-controlled spec from Metropolis Central). Once you start doing this, however, you can no longer call them RPA bots, as you no longer have that RPA bot simplicity which was the reason you started using them all in the first place.
Programming requires analysis, design, coding, testing, management, project planning, maintenance, bolshy programmers, buggy software, slipped deadlines, and all of those other nasty little problems which you sought to escape by deploying your RPA bots instead. RPA bots that are scripted are just programs pretending to be something that they’re not.
If the problem you wish to solve requires programming, then just bite the bullet and write it, or get someone else to write it. Use programmable RPA bots if you like but accept all the pain that programming brings along with it. If you think you can dispense with all of this with RPA, make double or trebly sure that you really are trying to automate a robotic process before you embark on the journey.
True RPA bots, i.e. those without programming, can only provide a solution to the simplest of possible problems. Unfortunately, the laws of wishful thinking seem to suggest that if you think you’ve got a cheap and simple problem you’ll convince yourself that all you need is a cheap and simple solution, and only realise you’ve made a costly mistake once you’re some way down the line deploying your RPA bots in the field.
CloudTrade doesn’t do RPA. Our problems are not robotic, we program. But if you do decide to use RPA to manage the simple and robotic tasks in your company, make sure you supply your bots with perfect data from CloudTrade. Give them reliable data so at least they can complete their simple tasks.
Want to know more about how CloudTrade’s technology can provide your bots with perfect data?
Download our guide outlining the 10 Top Tips to improve RPA Bots performance.
Is there a difference between systems based on AI and solutions using neural networks? And, if so, which of these approaches lies at the root of the CloudTrade data-extraction service? In this blog post, the second in a trilogy explaining the CloudTrade data-capture solution, Richard Develyn, CloudTrade CTO, answers these questions, colourfully depicting the role of neural networks from the time of the dinosaurs onwards.
In the middle of the Second World War an American behaviourist, and Harvard professor of psychology, called B.F. Skinner, “trained” pigeons so that they would direct specially modified missiles towards their targets, by pecking on the little windows on the front of the missile that the poor creatures were allowed to look out of. It was called Project Pigeon and though it never got past the Beta Test stage it did show considerable promise and even received $25,000 of US state funding.
I say that the pigeons were “trained”, in quotes, because they were never actually sat down in classrooms with exercise books and had the whole business of how to recognise a bomb’s target patiently explained to them. The pigeons were trained in the same way that neural networks are trained, i.e.: “peck on the window where the target is in front of you and you get some nice pigeon treats; if you don’t, or you get it wrong, then no pigeon treats for you”. Eventually, the pigeons figured it out, somehow, in much the same way that neural networks figure the answers to their problems out, somehow.
Determining how to guide a missile to its target might not seem too hard a problem – for a pigeon. One might consider it comparable to the problem of trying to find an invoice date in an invoice that’s never been seen before – for a neural network.
In June 2018, the largest neural network, built on supercomputers, had about 16 million neurons. That’s about the size of the brain of a frog. I’m sure there are bigger ones around now (neural networks, not frogs) but back then it was the biggest one in the whole wide world, and anything that we might be able to get hold of ourselves today is likely to be at least an order of magnitude smaller than that. Of course, you cannot draw a straight comparison between organic and synthetic neural networks, but for the sake of argument let’s assume that any sensible neural network we might be able to play with today is going to be of about the size of the brain of a frog.
The brain of a pigeon is actually about twenty times the size of the brain of a frog.
Back in the 1940s, of course, B.F. Skinner had a decided advantage when training pigeons. Pigeon brains are not totally untrained to begin with.
Charles Darwin had a particular fascination with pigeons when he was researching “On the Origin of Species”. He bred them himself and used his breeding as an analogy to describe what nature was getting up to in the wild. All of today’s pigeons descend from Rock Pigeons, which can be found all over the world and which humans have been training since the dawn of civilisation. The Ancient Greeks used pigeons to send the results of the Olympic Games from town to town as early as the eighth century BC. Genghis Khan created the first pigeon-based internet across his whole empire all the way back in the 12th century.
If you really want to know how long a pigeon brain has been “learning”, however, you probably need to trace them back to their roots, which turns out to be the, now infamous, Velociraptor found in the Jurassic period (and Steven Spielberg movies). Assuming that our humble pigeon had a change of heart at the end of that particular epoch and re-set its neural network to focus more on pigeony things rather than the ripping up of other animals, then our pigeon brain has had about 150 million years to perfect itself, which is quite a long time to train a neural network, and goes some way to explaining why pigeons are something like three times faster than human beings at processing visual information (even though humans brains are around three hundred times bigger – you’ll be pleased to hear).
If all of this seems to fly in the face of the much-lauded accomplishments of neural networks today, then take a bit of time to scratch below the surface of the headlines. Facial recognition works well when people don’t look too much like each other, don’t try to disguise themselves such as by wearing paper masks, don’t do annoying things like wear t-shirts with other people’s faces on them, or wear any of that interesting make up you can find on the internet designed to throw the algorithms off. Language translation works well when there is no need to understand what the sentences being translated actually mean; the step change in difficulty between text-substitution style translation and what one might call “cognitive” translation is immense.
The rise in the profile of neural networks over the last few years has come about not so much because of a rise in computing power but because of a rise in the amount of training material which our internet-based society has enabled. This rise in profile has fuelled a rise in interest, money, research and, I’m afraid, wishful thinking about what neural networks might be able to do for us in the future. We all of us have this very sci-fi based vision of computers as no longer needing to be programmed but rather able to magically program themselves if they’re shown the right amount of correct answers. Neural networks, however, are not self-programming computers; they’re vast, convoluted, and actually pretty incomprehensible pattern-matching engines. Their beauty is that they can be “taught” in the same way that we train animals, i.e. not by instructions, but by showing them lots of examples of what is right and what is wrong. Their disadvantages are that (a) they need a lot of training and (b), again just like animals, they sometimes just go wrong anyway without bothering to provide us with an explanation.
Ultimately, that was the reason why B.F. Skinner’s experiments with trained pigeons in missiles would never have taken off the ground (if you’ll excuse the pun). No one was going to be particularly happy about having weapons of mass destruction guided to their target by a bunch of pigeons pecking away at a screen.
This problem of “explainability”, as it is known in the AI world, is called the AI Black Box problem, though it should really be termed the Neural Network Black Box problem as AI and neural networks are not the same thing. “Explainability” is only half the story; the real requirement is “instructability”. Unfortunately, we can no more instruct neural networks to behave in particular ways than we can instruct our pet dog not to pee on the sofa. We can train it (them) and hope they get the message right, eventually, but we can’t program them in the same way that we can program computers.
That’s not to say that neural networks don’t have a role in solving the problems faced by IT today, even including to some degree those of identifying data from documents as we do in CloudTrade. If your requirements are simple, your training data set large, you don’t care if it gets it wrong and you’re not going to ask it to explain itself, then a neural network might well be the thing for you. In terms of where we see the future for our core technology, however, which is all about increasing in sophistication rather than decreasing it, then it’s not so wondrously exciting for us, though it will still have a role to play as an advisor in our latest developments, project Grandalf. Neural networks are great for suggesting to humans where to look for things or where to get ideas. As advisors, you don’t mind if they get it wrong, all help is useful, but there’s no way you’re going to hand over the reins to them.
AI has never, however, been just about neural networks. If you were to ask me the question “Is what you’re doing here at CloudTrade AI?” then I would say, “Yes, but not the neural-network flavour of AI”.
John McCarthy, an American computer scientist who was one of the founders of the discipline of artificial intelligence, felt that machines did not need to simulate human thought at all, but should rather try to implement the essence of abstract reasoning and problem-solving, regardless of whether people used the same algorithms. Pamela McCorduck, in her 2004 paper “Machines who Think”, summarised it as follows, writing that there are “two major branches of artificial intelligence: one aimed at producing intelligent behaviour regardless of how it was accomplished, and the other aimed at modelling intelligent processes found in nature, particularly human ones”.
If you think about the traditional human problem that AI was set as a challenge – winning a game of chess against a grandmaster – the answer in the end didn’t come from building the neural-network equivalent of a human brain (which is well outside of our capabilities anyway) but instead from programming a normal computer using normal software that implemented very understandable algorithms discovered by people who studied how the game was played. That’s how most of AI happens.
CloudTrade’s technology works in exactly the same way. We use a variant of natural language processing to program our core engine, “Gramatica”, to understand documents in the same way that we understand them as humans, i.e. in the cognitive sense, rather than trying to simulate the way that our neurons in our neural-network brains are firing across to each other. Much like with the chess-playing programs that we have today, Gramatica is the obvious way to solve this problem. It does carry with it the irksome task of having to program the thing to deal with each different type of document individually, but the dreams of having a neural-network style engine which self-programs itself to magically produce an answer are a long way from reality. Dreams are seductive, of course, but businesses are built on what is sensibly achievable today.
CloudTrade uses natural language processing to solve the problem of understanding and extracting meaningful data from documents. Natural language processing is a well-recognised branch of AI. CloudTrade doesn’t, at the moment, use neural networks in its solution, but we are intending to introduce it in the next generation of our software called “Project Grandalf”. AI is indeed at the core of what CloudTrade does, and it is interesting and exciting for us. We like to think that we have helped to push that technology forwards with our initial patent, and it has enabled us to build a successful business out of it with hundreds of happy customers. Who knows, perhaps with Grandalf, and more neural-network advances, other patents will follow.
If you’d like to reach out to me to find out more information or to discuss anything mentioned in this blog, please connect with me on LinkedIn.
https://i0.wp.com/www.cloud-trade.com/wp-content/uploads/2021/01/Artificial-Intelligence.png?fit=1600%2C900&ssl=19001600Richard Develyn/wp-content/uploads/2019/04/CloudTradeLOGO.pngRichard Develyn2021-01-13 17:09:452021-01-13 17:09:48Is it AI?
As the new year begins, it is an ideal time to reflect on the previous year and what we learnt during this time. As we all know, 2020 was a bit of a strange year, but CloudTrade still managed to grow and hire more colleagues, all while adapting to the ever-changing restrictions of various lockdowns. In this blog post CloudTrade CEO, David Cocks, takes a look back at last year and describes how, in spite of the severe challenges faced by everyone in 2020, CloudTrade has had a remarkably good year.
I co-founded CloudTrade in 2009 and we have been working hard to develop the business for 11 years. It has been fun, and we are looking forward to the New Year. It has been an interesting year. Obviously, starting our financial year in April 2020 meant that we had a few problems, like everyone else, as the world went into global lockdown. Our transaction volumes dropped by about 20% in those early two months, but by the time we got to September we had recovered lost volume. October and November proved to be record months. I am now confident that we will have had a good year in 2020, and actually we will finish the financial year with over 35% growth. This is a great achievement.
Internationalisation is the way forward
Everyone has worked really hard despite all the obstacles put in our way. CloudTrade’s vision has always been to help businesses enable global trade. Even with the Covid epidemic causing problems of business continuity with people obliged to work at home, we feel we have achieved this vision, not only for our customers but for ourselves. CloudTrade has always been quite modest in its marketing, and quite modest about itself. Our vison as we move forward is that we shout a little louder from the rooftops, and that we take on a more international approach. Internationalisation is the vision for CloudTrade in 2021.
Advances in on-demand scalability and machine learning
Obviously, at heart, CloudTrade is a tech company. This year we have put an enormous amount of effort into increasing the capability of our tech so we can deliver new services to our customers. There are two very exciting new projects that we have been working on. The first one is to transform our core software into a true microservices application hosted in Microsoft Azure. This will give us on-demand scalability, driving down costs and increasing performance. The second exciting project that we have under way is to make greater use of machine learning. CloudTrade has always been an AI company using our patented, natural-language processing engine, and although there is a lot of excitement at the moment about the potential of machine learning, we know that in practice a combined machine-learning and rules-based system is the best way to solve our customers’ problems. CloudTrade is leading the world in the development of a hybrid, machine-learning and natural-language rules system for the processing of business documents.
Collaboration with partners
We are delighted to have had a great deal of success both with our established partners and our new partners in 2020. We have been working hard with SAP Ariba, with specifically a lot of activity in the US. Many big customers of SAP Ariba have now adopted CloudTrade as their PDF-invoicing solution. We are also excited at having found new partners. Two which come immediately to mind are Pagero, a very successful Swedish company who have an enormous presence in the EU and a growing business in the UK and US, and also Embridge, a new partner here in the UK who are preeminent in the implementation of Unit4 systems.
Thank you to staff, customers and partners
I would like to thank all of the CloudTrade teams. The Operations team have worked very hard implementing new customers across the globe in some very challenging environments. The Development team have managed to master all this new technology including the Kubernetes container technology which really is state of the art. The Sales team have managed to excite new customers into the CloudTrade network, and our Marketing team have raised CloudTrade’s profile both in the US and in Europe. As we come up to Christmas and the end of 2020, I would like to say a big thank you to all the staff at CloudTrade, to our customers, and to our partners. It is thanks to all their hard work and commitment that we have had a very successful year.
David has put together a short video highlighting the successes of the last year and our vision for 2021.
https://i0.wp.com/www.cloud-trade.com/wp-content/uploads/2021/01/AdobeStock_391928266-v2.jpg?fit=1000%2C667&ssl=16671000David Cocks, CEO/wp-content/uploads/2019/04/CloudTradeLOGO.pngDavid Cocks, CEO2021-01-06 15:23:572021-01-06 16:52:42A message from David Cocks, our CEO
CloudTrade was established in 2009 in the UK, and the service is now available worldwide. Global customers expect geographic local representation which is provided through our wide network of partners. They have expertise in areas that CloudTrade does not: be that local business knowledge, technical integration with the customers’ end systems, or other details of their own ISV solutions.
Rebecca Bohms is CloudTrade Director of Business Development for North America. She has just completed her first six months, where she’s spent her time working for both the company HQ in the UK and for the US office in the Boston area. She says she finds it inspirational to be working with top leaders in the data-capture industry, and enjoys this highly competitive space. She explains here in her first CloudTrade blog post the significance of the relationship that CloudTrade has with its partners.
As my British colleagues say – we make it ‘easy peasy lemon squeezy’
I had never before come across a company quite like CloudTrade, and was charmed by these intriguing British guys, some of the data transformation industry’s top talent, who had developed a solution to set themselves apart. An amazing capture solution which provides 100% data accuracy with no touch on the part of the customer. When I saw it, I was instantly hooked. I knew that as I built up my North American territory, it would be a pleasure to introduce CloudTrade’s solutions and people to those I engaged with.
Getting to know the rest of the CloudTrade team over the last six months, has been great! It is refreshing to work with people who are approaching the market so very uniquely All the way from Development through to Sales and Delivery, the people I work with are driving for success, from an out-of-the-box perspective, and they do it in a way that is friendly, efficient and cooperative with all parties involved. They are very easy to work with and I’m always pleased to introduce them to my network.
It is my responsibility to find, feed, water and generally nurture our important North American partner relationships. Not only do I recruit, train, and establish the initial relationships, but I then walk with them through marketing, co-selling and delivery, in order to aid in success. I continue to support them in their endeavours throughout the lifetime of the relationship, and consider it an honour to provide this vital link.
Partners are indispensable in the CloudTrade ecosystem; the core business is built on strong relationships through our indirect business model. Our partners are the essential intermediaries between CloudTrade and our end customers and it’s a model which is benefiting all by delivering profitable, long-term revenue streams. If you’re interested in a partnership with CloudTrade, let me show you what that looks like and how we can help your business.
So, how are we bringing value to your business?
CloudTrade provides a Microsoft-Azure-hosted, multi-tenanted, automated, data-capture service with a patented, natural-language engine. Processing is available 24/7 worldwide and is purpose-built for integration with our partners’ own services. While all that sounds quite high tech and impressive, we really do tailor integrations for each partners data requirements, as standard – it is our ‘bread and butter’ and comes hassle free.
In a SaaS world, state-of-the-art solutions are made up of interconnected micro-services. We at CloudTrade focus on being best-of-breed in our technical specialism, which is delivered as a cloud-based service, purpose built for integration into partners’ ecosystems. Our partners use their own technical and business expertise to deliver complete solutions to fulfil their customers’ requirements.
There is never a conflict of interest between CloudTrade and its partners. It’s understood that CloudTrade’s customisable service is usually only one part of a complex B2B solution that you provide. We know we are experts in what we do and have no intention of extending our reach into other aspects of the B2B environment and we support partners to deliver their solution to their customers with CloudTrade as an add-on or embedded as a component.
What does a CloudTrade partnership look like?
At CloudTrade, we contract with partners so that you can provide our services to your customers, and the commercial agreement is always between the partners and their customers. CloudTrade embraces two types of partners: Solutions Partners and Platform Partners.
For a Solutions Partner, CloudTrade is one discrete aspect of the VAR’s overall solution, normally identifiable as a CloudTrade service, but could be white-labelled and re-branded by the partner (we don’t mind!). The customer’s IT system in receipt of the output from CloudTrade can be either cloud-based or on-premise.
For a Platform Partner, they will typically have their own ISV cloud-based technology and CloudTrade feeds its output into the partner’s own system for processing. You as the partner, may then pass the data on to a specific customer system, if required. This CloudTrade component is not usually directly visible to the end customer, either technically or commercially.
But, however you partner with us, the quality of service and data delivery remains the same. A managed-service with real humans to provide ongoing support, ensuring optimal data delivery for your customers – irrespective if you’d prefer we liaise with you or your customers directly.
How do we benefit your business and customers?
CloudTrade’s service is designed for pay-as-you-use pricing, which provides you with long-term, recurring revenue. Your customers benefit from a low-capital-cost solution, and they appreciate that the cost of service they pay for corresponds directly to the business benefits. CloudTrade’s partners enjoy a year-on-year customer retention rate, which averages over 95%.
Our partners get long-term, revenue-stream sharing through the fees charged to their customers. CloudTrade offers flexible charges: either per customer for a Solution Partner, where requirements of each customer may vary; or wholesale pricing, more applicable for the Platform Partner where CloudTrade’s transaction is only one small part of the over-all ISV value-add. In addition, partners can choose whether to earn further service revenue (e.g. for technical integration, project management, configuration, and ongoing support) or sub-contract this work to CloudTrade.
If this article has got you thinking about how CloudTrade could partner with your business and you’d like to know more, download our Partner Guide to get further details or alternatively you can book a quick call with me and I can answer any questions you may have. To book a call with Rebecca Bohms – click here.
Download the complete guide
Interested in bringing CloudTrade’s technology to your customers and getting sustainable revenue for your business?
https://i1.wp.com/www.cloud-trade.com/wp-content/uploads/2020/12/Tursted-Partner.png?fit=1600%2C900&ssl=19001600Rebecca Bohms/wp-content/uploads/2019/04/CloudTradeLOGO.pngRebecca Bohms2020-12-10 14:42:272021-01-05 14:21:30A partnership with CloudTrade – What does that look like?
Can a technical service really be 100% reliable? In this blog post, Richard Develyn, CloudTrade CTO, with a nod to Heisenberg, looks at what is meant by 100% accuracy in the world of computers. He discusses the shortcomings of OCR technology, and describes how CloudTrade has devised a systematic methodology to reach the goal of offering a service that is 100% accurate.
How is it that one can claim to offer a service which is 100% accurate? One hundred per cent seems too absolute; too certain; too devoid of margin of error. Nothing is 100% accurate after all, is it?
Perhaps you think it isn’t because you’ve heard of something called Heisenberg’s Uncertainty Principle. Even if you don’t exactly know what that is, the fact that it has the word “uncertainty” in the middle of it and is clearly written by a very clever German physicist probably suggests to you that no one should ever make the claim of being 100% certain about anything.
Well, ok, but Heisenberg’s Uncertainty Principle applies at the quantum level, and if it’s going to affect anything it’ll probably kick in when processors become so small that computers start to become “quantumly” unreliable (unless, of course, quantum computers somehow or another prevent it).
But I doubt you came to this blog to read about quantum computers.
Are computers really 100% accurate?
Normal computers are, in fact, 100% reliable, in much the same way that gravity is 100% reliable. The last time that we witnessed a mistake being made with a computer processor was in 1994 with the now infamous (if you happen to move in those circles) Pentium FDIV floating point hardware bug that apparently resulted in 1 in every 9 billion floating point divisions coming out with the wrong answer. That might not seem too terrible, but it was a pretty serious problem at the time, causing Intel to recall the chip at the cost of just under half a billion dollars, which would be three quarters of a billion dollars in today’s money.
You can’t really blame the Pentium FDIV processor for the mistake, though. The poor bit of silicone was only doing what it was told. The problem happened because human engineers made a mistake when they built it. This hasn’t happened since, not because human engineers no longer make mistakes, but because human engineers have improved the way in which they test for and correct the mistakes that they make.
How can unreliable people build reliable systems?
The reason people are sceptical about a claim for 100% accuracy is that they imagine that everything must map down to some sort of human process in the end, and human beings are notoriously not 100% reliable. The people who produce computer processors, however, seemed to have bucked that trend.
About ten years earlier, in the world of software, Donald Knuth, an eminent computer scientist, offered a reward of $2.56, doubling every year, to anyone who could find a bug in his very sophisticated typesetting application that he’d written called Tex. There were bugs found at first, admittedly, and Knuth duly paid out, but even though the software continues to have widespread use to this day no one has reported a new bug in it for about the last 12 years.
So, it would seem that it’s possible to produce 100% reliable software as well as 100% reliable hardware. Plenty of software is, actually. Sure, plenty isn’t, but the majority of the stuff that controls the critical aspects of our lives is 100% reliable. We’d soon know if it wasn’t. It might not be 100% reliable when it first comes out but, rather like Donald Knuth’s Tex program, it gets to 100% accuracy with a bit of time and effort.
Here’s the key question: how is it possible for computers and computer programs to be 100% reliable when they are built by people who clearly aren’t?
It really comes down to three things:
Having a well-understood and limited problem to solve
Having the right tools to solve the problem
Ironing out the bugs
The problem with OCR
Optical Character Recognition (OCR), for example, as a technology, fails to achieve 100% reliability because of point (1) – the problem is not well understood or limited in its scope. There are many ways of representing letters to the human eye – some estimates give the number of fonts in existence today at about half a million. These fonts don’t adhere to some sort of hard-line rule about what differentiates a “b” from an “h” or an “I” from a “j”. They’re “artistic”, and we all know what that means: they don’t adhere to rules. Add to that the imperfections that you get from scanning paper images and you can see how OCR is really trying to solve an impossible problem.
Identifying the problem
We don’t try to solve the OCR problem; we avoid it entirely by extracting raw data from documents which already have that data unambiguously present within them. Data dumps are of no use to anyone, of course, so where we, at CloudTrade, concentrate all of our efforts is on solving the problems of data understanding, allowing us to properly identify and label data before we pass it on to our clients. These problems are well defined, allowing us to achieve 100% accuracy by following the next two steps on the list.
Choosing the right tools
First of all, we use the right tools. “Let’s get to the moon” might be a very well-defined problem but you’re not going to get there with a hammer and chisel. The better the tools you have, of course, the easier the problem is to solve. We have invested many years of development at CloudTrade in producing a rules-writing engine which allows people, without an IT background, after about a month of training, to write the necessary rules to extract and interpret data from a document in about fifteen minutes to one hour depending on its complexity. This is the key to our success as a company.
Ironing out the bugs
Of course, sometimes the rules writers get it wrong, because they’re only human, and that’s where point (3) comes in. When we make mistakes, we fix them, and fixed mistakes stay fixed.
The trick for getting to 100% accuracy is in having a repeatable process that you can correct as you go along. You can’t get to this sort of reliability if you use people in your processes because people can’t be fixed in the same way that computers can (even the most ambitious psychoanalyst in the world wouldn’t try to make that claim). Neural Networks, which sort of simulate human thinking, can’t be fixed either because we don’t actually understand how they reason any more than we understand how human beings reason. This is an area of considerable research these days because our inability to discuss reasoning with neural networks greatly limits our ability to use them. Perhaps one day we’ll have neural network psychoanalysts. I wonder whether they’ll also be neural networks. The mind boggles.
So in conclusion, the reason that we can justifiably claim to deliver a 100% accurate service is because of these three key facts:
We limit the problem that we’re trying to solve to something well scoped and understood, because we avoid OCR
We have a system in place purpose-built to solve our particular problem
We have processes in place to correct any mistakes that we might make when we use it.
No human errors, no OCR errors, no neural network errors. Just a repeatable programmable system. That’s how we get to 100%.
https://i1.wp.com/www.cloud-trade.com/wp-content/uploads/2020/12/AdobeStock_389314619resized.jpg?fit=1500%2C844&ssl=18441500Richard Develyn/wp-content/uploads/2019/04/CloudTradeLOGO.pngRichard Develyn2020-12-02 12:30:002020-12-01 17:30:02Can a technical service really be 100% reliable?
When faced with today’s significant challenges, resilience is key. Steve Britton, CloudTrade Director of EMEA Sales, shares here in the blog post his passion for motorsport, and explains how the verve and determination seen on the racetrack is just what is currently required by shared service centres and global business services. Not only do business leaders need to show resolve, but they must also embrace innovation to survive. He explains how the CloudTrade document-processing service enables businesses to move on from the considerable limitations of using OCR systems. The time for disruptive change is now. Do you have process resilience?
We live in challenging times: Covid-19, lockdowns, presidential elections and a faltering economy. What a year, and on top of all this we need to run our businesses to pay bills and our employees, and to deliver a return to our shareholders.
I want to talk about the challenges we face with the collection of data required to run our businesses, and how critical this is to remain competitive. Without data we can trust, how are we meant to run our businesses, pay bills accurately, process orders efficiently, and satisfy our auditors and regulators?
Why challenge the status quo?
Is this a time to batten down the hatches and weather the storm, or should we rise to the challenge and take this opportunity to embrace change and reap the rewards? In business we must innovate to remain competitive. Even more so now. We need to be resilient to the demands we face; we can’t slam the breaks on change and hope that will be enough. Now is the time to not only face the issues head on, but we must challenge the status quo if we are to succeed. Our competitors will seize the initiative if we don’t.
I am a petrol head and drove a rally car semi-professionally for a while, but children, work demands, and grey hairs have put an end to that. To satisfy my passion now I watch Formula 1 and the WRC whenever I can. Motor sport is hugely competitive and constantly challenged with new FIA regulations; the successful teams embrace change and use this to push the boundaries; they constantly innovate and hone their machines to be world class. There is no “I” in team, and indeed without all the team members working together in a coordinated but agile way, success would not happen.
What does Lewis Hamilton have in common with business leaders?
However, as with every great team there is the ‘one’ person that brings them together: in the case of motor sport, it’s the one who pilots the car. This is the sharp end, where the rubber meets the road. The driver, confident in the design and build of the car, takes the machine to its limits, pushing the vehicle and the team to achieve that world-class status. We have all been amazed at the tenacity and sheer determination that has elevated Lewis Hamilton to the position of holding the greatest number of F1 wins ever. Many will argue that the likes of Fangio, Moss, Stewart and Senna were in a different league, and indeed their era of motor sport and car development were very different – all heroes in my book – but one thing they had was an unquenchable desire to succeed, and this required constant development of man and machine and a sheer determination to win above all odds.
This necessity for innovation and the continued drive to excellence is the same for business leaders, especially when tackling the challenges we face today. We all benefit from motorsport innovation. Consider how carbon fibres, turbo technology, electric motors and battery technology impact on our daily lives.
The document-processing story
Shared service centres and global business services have innovated and evolved from cost centres to profit contributors. The early days of an accounts payable focus have expanded to embrace all aspects of PTP and OTC. It was simply a case of innovate and add value to survive. I remember in the early 2000s how scan-to-fiche migrated to scan-to-tape and computer-output-to-laser-disk like the HP Surestore and NAS storage. These on-premise solutions rapidly migrated to the ‘Cloud’ with all the associated benefits of free text search, unlimited storage and instant access to data. This created the ‘Big-Data’ era and the need to control data exchange and storage, supported by legislation triggered by the likes of Sarbanes Oxley and the Enron scandals, and more recently by GDPR requirements, to protect how we use the data we collect. Our businesses are managed and controlled by data. Incorrect or false data can have a devastating impact. Most data that businesses rely on is created by third parties and then has to be passed to us for processing, action and analysis.
Document processing: cost versus accuracy
My focus for the last 21 years has been business-process automation, and specifically the digital transformation of inbound documents. These documents create the very data we rely on to manage our businesses. When I started in this industry OCR had a purpose as most documents were received as images or on paper, but OCR could never deliver 100% data accuracy and always required manual intervention. To keep the costs down, the industry moved the capture offshore to low-cost centres. Very often, however, low cost meant low accuracy. There was a choice between basic, low-cost capture with re-keying and error correction, or maintaining the FTE count onshore to ensure accuracy.
The OCR industry had to improve the extraction quality to support the offshore demand, so they bolted-on artificial intelligence and machine learning to try and compensate for these errors. After years of refinement, the core technology still relied on converting an image file using OCR. The problem is OCR systems have not been able to reach the accuracy levels required to enable end-to-end automation. With re-keying and exception management the actual cost of OCR varies enormously and can be more than $10/invoice in some circumstances. We must not forget that PO and vendor compliance are very important factors when looking to automate a process like accounts payable, but the fundamental challenge is still: the need to accurately extract the required data from the in-bound document.
New-wave digital transformation
In recent years, the market has changed and with the migration to the cloud for billing and finance applications and the rapid move to digital submission (accelerated by Covid-19), OCR is being replaced as the demand diminishes. We are now welcoming the next wave of digital transformation for human-readable documents.
Here at CloudTrade we lead the way in converting human-readable documents to an actionable machine-readable output with 100% data accuracy supporting true touchless processing. We do not apply OCR to application-generated (digital) documents. Instead, we have developed patent-protected technology delivered via a managed SaaS model to extract and analyse the technical elements of a document. We do this without error and guarantee 100% data accuracy. The extraction is the first part of our process, the second and equally important process is to understand the content and its context, applying logic and rules to ensure the output will meet the receiving application’s specific requirements to enable touchless processing.
So, if you need to process a supplier’s invoice, customer order, shipping document, application, contract, claim etc, and if the document is electronically generated, we can process within minutes of receipt and provide an end-to-end touchless process, with guaranteed accuracy you can trust.
Business rules, data validations, content enrichment and workflow actions are all part of the service. Sender format updates and rule changes are automatically accommodated, and the service runs 24/7. We support clients across the globe and interface to multiple back-end systems (FMS/ERP/DMS etc).
CloudTrade’s document-processing service: fast, precise, different
Our implementation and outreach programs ensure your time-to-value can be measured in days and not months. In most cases, there is no change for the sending party as existing email boxes and file-transfer protocols can be accommodated. The sender bears no extra costs (e.g. printing, scans, postage, stationery), therefore adoption is high.
We provide an innovative, rapid ROI, low-touch, fully managed SaaS service. We push the boundaries in process automation and innovation, delivering tangible value to our customers and partners. Like an F1 team, CloudTrade has a passion for success and customer excellence. What we do is different – we are a disrupter. Thanks to our hugely experienced management team, you can have the confidence in the service we deliver in the race to the top.
We welcome enquiries and will be happy to quote for any document type, language or volume. The more complex the requirement, the better – and remember you get 100% data accuracy that you can trust.
For a quick informal chat about how we can solve your data capture requirements, book 15 mins in with me.
https://i1.wp.com/www.cloud-trade.com/wp-content/uploads/2020/11/AdobeStock_110861591-scaled.jpeg?fit=2560%2C1448&ssl=114482560Steve Britton, Director of Sales EMEA/wp-content/uploads/2019/04/CloudTradeLOGO.pngSteve Britton, Director of Sales EMEA2020-11-25 11:00:082020-11-25 16:15:50Document Processing: Time for a gear change?