What is our primary use case?
Nanonets is primarily used for table extraction from native and scanned PDFs. I have implemented Nanonets for sales order automation, as we work with different manufacturing units across various countries worldwide, and the sales orders received by each unit or factory are in different formats. The PDFs contain complex multiple tables within them, and we need to extract the sales order number, items listed in the sales order, the date, item quantities, item names, and prices. These details must be extracted from sales orders that contain multiple tables on the same page, which we need to identify and extract accurately.
Nanonets has helped us capture these details into a structured format that we can integrate into our SAP ERP system to update that data.
We have another use case involving the extraction of another table as well, but it is not as complex; it is a simple table where we are utilizing Nanonets.
What is most valuable?
The best feature of Nanonets is complex table extraction, because it identifies multiple tables in the same document and provides raw HTML code, which helps us identify the items specifically. We can also capture signatures and watermarks, which are cool features of Nanonets where other OCR engines lack.
Signatures need to be stored, and watermarks help us identify whether documents are paid or not in terms of invoices. Usually, scanned PDFs have watermarks such as 'paid,' and extracting that paid keyword from the document helps the automation workflow decide the next step.
Nanonets has positively impacted my organization by providing a solution that works for us as developers. Before using Nanonets, we tried multiple built-in OCRs that are part of the automation tool, including Tesseract and open-source tools, Microsoft OCR, and Google OCR. These all failed and did not work out, but we needed to find an OCR that could do the job perfectly with greater accuracy.
We evaluated multiple OCR engines, and our organization found Nanonets more suitable in terms of cost and the units consumed when processing pages. It has been a good journey in terms of receiving results from Nanonets with good accuracy, which helped the automation and also reduced the manual time for business users to extract data manually and type that into the ERP. In our automation journey, it has helped significantly to streamline the automation process.
What needs improvement?
I have observed that while training Nanonets, we must provide a larger number of examples or documents. When I trained the model, it usually requested around 50 documents as a dataset to train the model. I found this very difficult because business users are not very helpful in providing such a large number of documents; we usually have around two, three, or five.
It would be helpful if we could start training the model with limited datasets and then have an option to always improve the model by providing more datasets as we progress through the journey, but it should not be a blocker at the first stage where you need to provide at least 50 samples for a model to train.
For how long have I used the solution?
I have been using Nanonets for nearly two years.
What other advice do I have?
I cannot speak to the exact cost, but I can say Nanonets saved around six hours per day for a business user for a single country. This was a scalable project which we implemented for multiple regions, but if you consider a single region, it saved around six hours per day of manual work for a business user.
I found the user interface acceptable as well as the integration; the API which we use to pull and push data and get the results back is quite familiar and developer-friendly, so I have no negative comments on that.
Security-wise, Nanonets has guardrails to protect the data, which we can host on both on-premise and cloud. Apart from that, I have not explored the security and governance extensively. I would rate this review an 8 out of 10.
Which deployment model are you using for this solution?
On-premises
