InvoiceNER
InvoiceNER is a small, on-device cross NER model from the FlowX OpenNER family. Developed by FlowX.AI. Runs 100% on-premise / air-gapped, so no data leaves your boundary.
What it does
- Task: token-classification
- Base model:
answerdotai/ModernBERT-base - Entity types (9): DATE, IBAN, INVOICE_NO, NET, PO_NO, SUPPLIER, TAX, TOTAL, VAT_ID
- Trained on: synthetic commercial invoices.
- Runtime: CPU, Apple Silicon, one GPU, or browser/edge via ONNX (INT8). ~100-160 ms/doc on CPU.
Evaluation
Held-out F1 on synthetic data: 1.0000. Read that as a pipeline check, not as accuracy on your documents.
Train and test are drawn from the same generator, so a rule of the form "the entity sits at position N of template T" is sufficient to score on the test split, and the reported test loss of 5.67e-07 is consistent with close to that having been learned. Human annotators do not agree with each other at 1.0 on this task.
What makes that more than a caveat is that two models from this same pipeline did not reach 1.0: flowxai/filingtag scores 0.6444 across 139 labels, and flowxai/ibandetect scores 0.9488. The pipeline is capable of reporting a number below 1.0. So a 1.0 here says the generated task was trivially separable, rather than that the model is perfect.
There is no per-label breakdown, only this aggregate, so it cannot tell you whether the label you depend on is one of the ones the model is good at. An aggregate hides the tail.
Validate on your own documents before production use. Treat 1.0000 as evidence that training converged and the pipeline is wired up correctly, and as nothing more.
What this model does not do
It labels spans. It does not validate them, and nothing in this repository does: no check digit is verified anywhere here, not IBAN mod-97, not the Luhn algorithm, not ISIN, LEI, VIN or ISO-6346. A span this model labels as an identifier may not be a valid identifier. Validate downstream if your use needs that guarantee.
Correction, 2026-09-14. Until this date the card claimed that identifiers are "validated by checksum (IBAN mod-97, card Luhn, ISIN/LEI, container ISO-6346, VIN, national IDs), a correctness guarantee general LLMs lack". That sentence was shared boilerplate across the OpenNER family and it was not true of any model in it. These repositories contain a config, weights, an ONNX export, a tokenizer and a metrics file, and no validation code of any kind. If you relied on that sentence, the guarantee it described does not exist and never did.
The licence note at the foot of this card says the model was trained on "synthetic, checksum-validated data". That is a statement about how the training corpus was generated. It is not a statement about anything this model checks when you run it, and the two were being read as one claim.
Why a small model
Fine-tuned encoders match or beat frontier LLMs on structured, convention-bound extraction, at a fraction of the latency and cost, with zero data egress.
Usage
from transformers import AutoTokenizer, AutoModelForTokenClassification
tok = AutoTokenizer.from_pretrained("flowxai/invoicener")
model = AutoModelForTokenClassification.from_pretrained("flowxai/invoicener")
License & attribution
Licensed under the Apache License 2.0. Copyright 2026 FlowX.AI (https://flowx.ai). See the NOTICE file. Trained on synthetic, checksum-validated data.
Part of the FlowX OpenNER model family.