4 ms·
>> This really needs a dataset to go with it. Addressed in the disclaimer section. :)
by enraged_camel 6y ago
>> This really needs a dataset to go with it.
Addressed in the disclaimer section. :)
- jacquesm 6y agoYes. Let me outline some of the challenges in this field: invoice information extraction is a subset of forms parsing, which is for many companies a hellishly difficult problem to deal with. The more companies are automated the more such information will be presented in a way that is machine readable, which means you will only have to do field matching rather than actually reading the field. OCR is anything but perfect resulting in errors creeping into digitized forms requiring human review. This relegates most of these solutions to aids for a human reviewer rather than a zero touch process. Finally, when working with international customers and suppliers you will have to be able to concurrently deal with a lot of different kinds of forms and languages which may require a step prior to the forms extraction that will decide what language the form is in and what kind of form it is. For each form type that you intend to extract data from you will need a substantial training database. The good news is as you use it you build up more data but for legal reasons you may not be able to use that data to train on. So that's why it really needs a dataset. One way to get one is to generate it based on a real dataset. I think that stands a much higher chance of happening than that some company will ship their - highly confidential - invoice stack to an unknown entity to make it world readable. That would likely cause that company serious problems and their legal department would never sign off on it.