Live Test vs .net solution
We are experiencing some differences between the information we get in the Live Test and the results in our .net solution json file.
For instance values appear in a certain way in Live Test and the I run the .net solution and the results are different.
We are using Mindee .NET client library version 3.29 rc3.
Log in to comment and vote
Comments14
Ricardo Silva
Jul 17, 2025
I understand the system is still under development, and I expected there might be some bugs or limitations with new tools. However, I was under the impression that at least version 2 would perform at the same level as version 1 — if not better. Unfortunately, that hasn’t been the case so far.
In our experience, version 2 has shown regressions in areas that previously worked well, which is affecting reliability and confidence in the upgrade.
Tipically we are facing issues with:
1) Type casting - string for integer;
2) Value recognition: sometimes the system correctly interprets the comma as a decimal separator (e.g., "12,50" as twelve point five), but other times it does not, treating it incorrectly or ignoring it altogether. This inconsistency is affecting the accuracy of the extracted numerical values. In Portugal sometimes we use comma as separator and point, and this happens in both cases. (example: sometimes lets say Quantity Field 2,000 is taking 2.0 but sometimes in other documents it is treating 2000.0)
3) We’ve observed inconsistent results when scanning the same document multiple times. In some cases, the first scan successfully extracts all values, while a subsequent scan fails to do so, resulting in missing or incomplete data. In other cases, the opposite happens — the first scan misses data, but the second one captures it correctly.
In short, the output is not consistent between identical scans of the same invoice, even though the input remains unchanged. Comparing to Live Test also the results are inconsistent.
4) Most of the documents, Product code is coming null eventhough we have a value in document in the solution but it’s being recognized in green in Live Test.
5) For some of the documents, customer company registration is coming empty.
6) I also opened a different ticket here, reporting another strange case, where it recognizes the product code in first and third page but not in second.
Thank you, any help is appreciated.
Ianaré Sévi
Jul 18, 2025
For points 1 and 4, I will take a look at the .NET client and see if I can reproduce.
For the other topics, I’ve notified the data science team, someone should get back to you soon.
Thanks!
Sebastian Olivera Silvera
Jul 22, 2025
Hello Ricardo,
We’ve just released a new release candidate version which may help with the reading discrepancies between the platform and API readings.
Also, the syntax of the call & parameters has changed since the last releases, so I strongly advise you check out the documentation:
https://docs.mindee.com/getting-started/integrating-mindee
Please let us know whether this version solved your issues!
Best,
Sebastian
Ianaré Sévi
Jul 17, 2025
Hi,
The .NET solution is still under development, so your feedback helps a lot, thank you!
Are you having issues with:
value type casting in the client library, ie a string when it should be an integer?
the overall structure of the response object in the client, ie missing fields?
the actual value returned, ie “yellow” in Live Test and “green” in the client?
Thank you.
Ricardo Silva
Aug 22, 2025
Hi I’m already using a non RC version the 3.29
And there are still 2 issues:
The number 2 of the first post - value recognition.
I've been actively working on deploying version 2, but I'm encountering persistent issues with extracting a specific field, which is crucial for my use case.
I'm referring to the field unit_kg, which should be captured from the column labeled "Unit/KG" in the invoice documents. Despite updating both the RAG and Data Schema guidelines accordingly, the field is still not being detected as expected.
Details:
I’ve attached the document makro.pdf, where the "Unit/KG" column contains values for all items — and I’ve even filled in the column in RAG.
Current Guidelines:
RAG:
"When processing this type of invoice, the value for the field unit_kg must be extracted from the column labeled 'Unit/KG'. This column typically contains numeric values representing units (e.g., number of items per box), or weights in kilograms."
Data Schema:
"When processing invoices, the value for the field unit_kg must be extracted from the column labeled 'Unit/KG' and 'QTD/CX'. This column typically contains numeric values representing units (e.g., number of items per box), or weights in kilograms."
Request:
Could you please review why the unit_kg field is not being properly detected in makro.pdf, and advise on any changes I need to make to ensure consistent extraction?
This field is critical for my workflow, and I would really appreciate your support in resolving this.
Thank you in advance!
Ianaré Sévi
Aug 22, 2025
Hi, thanks for getting back to us with these details, it's very useful to us.
FYI when we released the stable (non-RC) version of the .NET lib, we changed all number fields to be cast to
Double.This in response to your initial feedback, to avoid issues with inconsistent API returns.
Regarding your two current issues, these appear to be model problems and not the .NET lib per se.
I'm asking the ML and data science teams to take a look, we'll get back to you shortly.
Thank you!
Laura Mitchell
Sep 8, 2025
•Merged request
•2 votes
Inconsistent Results Between Live Test and API Response
Hello Mindee Team,
We have encountered a critical issue while evaluating your platform. When using the same invoice and model, the results we receive through the Live Test interface differ significantly from the ones obtained via the API.
This inconsistency is highly problematic and undermines the reliability of your service for production use.
We are willing to provide the exact invoice file, API responses, screenshots, or any other information necessary to help you identify and resolve this issue as quickly as possible.
We would appreciate a prompt resolution, as this is currently blocking our decision-making process.
Best regards
Laura Mitchell
Aug 6, 2025
This is a bug not a feature request.
Charles Gaillard
Aug 6, 2025
Hello Laura,
Thank you for reporting this bug, can you send us the invoice file so that we can reproduce it ?
Laura Mitchell
Aug 6, 2025
Hello,
After consulting with management, I won’t be able to share the invoice with you.
Therefore, it might be best to close or delete this issue, especially since we are only experiencing the problem with that one specific invoice type — everything else works fine.
Thank you for your understanding.
Charles Gaillard
Aug 6, 2025
ok, thank you
Ianaré Sévi
Sep 8, 2025
We’ve identified the polygons as the cause of the discrepancy. We are actively working on harmonizing the results between polygons activated and not.