6 ms·

Almost any business that has physical suppliers or business customers. PDF is de-facto standard for any invoicing, POs, quotes, etc. If you solve the problem

Almost any business that has physical suppliers or business customers. PDF is de-facto standard for any invoicing, POs, quotes, etc. If you solve the problem you can effectively programmatically deal with invoicing/payments/ large parts of ordering/dispensing. It's a no brainer to add it on to almost any financial/procurement software that deals with inter business stuff. Any small-medium physical business can probably half their financial department if you can dependably solve this issue.

innomatics 7y ago
A business that invests in building a machine that reads data, produced by a 3rd party machine, using format intended for lay humans to read, is not investing in the right tech IMO. Small-mediums should be looking to consolidate buying through a few good suppliers and working with them directly to automate process, or adopting interchange formats. Problem for some small-business is the cost (process changes, licencing etc) of adopting interchange formats and working with large vendors is prohibitive at their scale e.g. the airline BSP system. I agree that solving the problem generally i.e. replacing an accounts payable staff person capable of processing arbitrary invoice documents will be comparable to self-driving in difficulty. If a company deals with a lot of a single type of PDF, then the approach could be economical. I am actually involved in a project looking at doing this with AWS Textract.
- speedplane 7y ago
  > A business that invests in building a machine that reads data, produced by a 3rd party machine, using format intended for lay humans to read, is not investing in the right tech IMO. Building machines that understand formats that are understood by humans is exactly what we should be doing. People should read, write, and process information in a format that is comfortable and optimized to them. Machines should bend to us, we should not bend to them. If businesses only dealt with machine readable formats, everyone's computer would still be using the command line. And there's real condescension in your post: > Small-mediums should be looking to consolidate buying through a few good suppliers and working with them directly to automate process You're saying that businesses need to change their business to accommodate data formats, but it should be the other way around.
  - kbutler 7y ago
    There has to be compromise. The proliferation of computers in business over the last 50 years is precisely because businesses can save money/expand capacity by adapting the business processes to the capabilities of the computers. Over that time, computers have become more friendly to humans, but businesses have adapted and humans been trained to use what computers can do.
ofrzeta 7y ago
Starting November 2020 in the EU machine-readable invoices will be mandatory in the public sector (https://eur-lex.europa.eu/eli/dir/2014/55/oj https://eur-lex.europa.eu/eli/dir/2014/55/oj). As far as I understand there are at least two standards (I know of in Germany): XRechnung and ZUGFeRD/Factur-X (which is PDF A/3 with embedded XML). http://fnfe-mpe.org/factur-x/factur-x_en/ http://fnfe-mpe.org/factur-x/factur-x_en/
- f3r3nc 7y ago
  seems to be only for the electronic invoicing in public procurement
  - Fire-Dragon-DoL 7y ago
    No, it's now for everyone. It was like that for a while
- sabas_ge 7y ago
  Electronic invoicing in Italy is a thing since a couple of years, mandatory since Jan 1st 2019...
tastyminerals 7y ago
Yes, most invoices are in PDF but only about 40% of them are native PDF meaning they are actual documents not scanned images converted to PDFs. There are are also compound PDF invoices which contain images. So, in order to extract data from them, one needs not only good PDF parser but an OCR engine too.
- speedplane 7y ago
  > So, in order to extract data from them, one needs not only good PDF parser but an OCR engine too. You can go further. Invoices often contain block sections of text with important terms of the invoice, such as shipping time information, insurance, warranties, etc. To build something that works universally, you also need very good natural language processing.
- thaumasiotes 7y ago
  If you're using an OCR engine to understand PDFs that are nothing but a scanned image embedded in a PDF... what do you need a PDF parser for? You can always just render an image of a document and then use that.
  - speedplane 7y ago
    > If you're using an OCR engine to understand PDFs that are nothing but a scanned image embedded in a PDF... what do you need a PDF parser for? This should be obvious, but the answer is because OCR engines are not terribly accurate. If you have a native PDF, you're far better off parsing the PDF then converting to an image and OCRing. But if OCR ever becomes perfect, then sure.
  - tastyminerals 7y ago
    For accuracy and speed. The market SOTA Abbyy is far from being accurate.
    - speedplane 7y ago
      > The market SOTA Abbyy is far from being accurate. While Abbyy is likely the best, it's also incredibly expensive. Roughly on the order of $0.01/page or maybe at best a tenth of that in high volume. For comparison, I run a bunch of OCR servers using the open source tesseract library. The machine-time on one of the major cloud providers works out to roughly $0.01 for 100-1000 pages.

innomatics 7y ago

A business that invests in building a machine that reads data, produced by a 3rd party machine, using format intended for lay humans to read, is not investing in the right tech IMO. Small-mediums should be looking to consolidate buying through a few good suppliers and working with them directly to automate process, or adopting interchange formats. Problem for some small-business is the cost (process changes, licencing etc) of adopting interchange formats and working with large vendors is prohibitive at their scale e.g. the airline BSP system. I agree that solving the problem generally i.e. replacing an accounts payable staff person capable of processing arbitrary invoice documents will be comparable to self-driving in difficulty. If a company deals with a lot of a single type of PDF, then the approach could be economical. I am actually involved in a project looking at doing this with AWS Textract.

speedplane 7y ago
> A business that invests in building a machine that reads data, produced by a 3rd party machine, using format intended for lay humans to read, is not investing in the right tech IMO. Building machines that understand formats that are understood by humans is exactly what we should be doing. People should read, write, and process information in a format that is comfortable and optimized to them. Machines should bend to us, we should not bend to them. If businesses only dealt with machine readable formats, everyone's computer would still be using the command line. And there's real condescension in your post: > Small-mediums should be looking to consolidate buying through a few good suppliers and working with them directly to automate process You're saying that businesses need to change their business to accommodate data formats, but it should be the other way around.
- kbutler 7y ago
  There has to be compromise. The proliferation of computers in business over the last 50 years is precisely because businesses can save money/expand capacity by adapting the business processes to the capabilities of the computers. Over that time, computers have become more friendly to humans, but businesses have adapted and humans been trained to use what computers can do.

ofrzeta 7y ago

Starting November 2020 in the EU machine-readable invoices will be mandatory in the public sector (https://eur-lex.europa.eu/eli/dir/2014/55/oj https://eur-lex.europa.eu/eli/dir/2014/55/oj). As far as I understand there are at least two standards (I know of in Germany): XRechnung and ZUGFeRD/Factur-X (which is PDF A/3 with embedded XML). http://fnfe-mpe.org/factur-x/factur-x_en/ http://fnfe-mpe.org/factur-x/factur-x_en/

f3r3nc 7y ago
seems to be only for the electronic invoicing in public procurement
- Fire-Dragon-DoL 7y ago
  No, it's now for everyone. It was like that for a while
sabas_ge 7y ago
Electronic invoicing in Italy is a thing since a couple of years, mandatory since Jan 1st 2019...

tastyminerals 7y ago

Yes, most invoices are in PDF but only about 40% of them are native PDF meaning they are actual documents not scanned images converted to PDFs. There are are also compound PDF invoices which contain images. So, in order to extract data from them, one needs not only good PDF parser but an OCR engine too.

speedplane 7y ago
> So, in order to extract data from them, one needs not only good PDF parser but an OCR engine too. You can go further. Invoices often contain block sections of text with important terms of the invoice, such as shipping time information, insurance, warranties, etc. To build something that works universally, you also need very good natural language processing.
thaumasiotes 7y ago
If you're using an OCR engine to understand PDFs that are nothing but a scanned image embedded in a PDF... what do you need a PDF parser for? You can always just render an image of a document and then use that.
- speedplane 7y ago
  > If you're using an OCR engine to understand PDFs that are nothing but a scanned image embedded in a PDF... what do you need a PDF parser for? This should be obvious, but the answer is because OCR engines are not terribly accurate. If you have a native PDF, you're far better off parsing the PDF then converting to an image and OCRing. But if OCR ever becomes perfect, then sure.
- tastyminerals 7y ago
  For accuracy and speed. The market SOTA Abbyy is far from being accurate.
  - speedplane 7y ago
    > The market SOTA Abbyy is far from being accurate. While Abbyy is likely the best, it's also incredibly expensive. Roughly on the order of $0.01/page or maybe at best a tenth of that in high volume. For comparison, I run a bunch of OCR servers using the open source tesseract library. The machine-time on one of the major cloud providers works out to roughly $0.01 for 100-1000 pages.