Mistral OCR czy Azure? Tańsza strona może oznaczać więcej kodu

Jeśli celem jest odczytanie całego dokumentu z zachowaniem jego struktury, podstawowy Mistral OCR jest bliższy temu zadaniu: procesor OCR Mistrala zwraca treść stron w Markdownie, a także informacje o tabelach i układzie. Gdy faktura ma zasilić system księgowy nazwanymi polami, sam odczyt tekstu oznacza dodatkową pracę nad ustaleniem, która wartość jest numerem faktury, terminem płatności czy kwotą należną.

Model faktur Azure Document Intelligence zwraca ustrukturyzowany JSON z rozpoznanymi polami i pozycjami faktury. To bliższy gotowemu wynikowi wybór dla księgowości, choć nadal wymaga mapowania danych do własnego systemu i kontroli błędów. Niższa cena odczytu strony może więc iść w parze z większą ilością kodu, jeśli potrzebnym wynikiem są pola faktury, a nie jej tekst.

Ta sama faktura prowadzi do dwóch różnych wyników

Przyjmijmy warunkowy przykład faktury z danymi sprzedawcy i nabywcy, terminem płatności, tabelą pozycji oraz podsumowaniem VAT. Podstawowy Mistral OCR oddaje tekst i strukturę strony. W wyniku można odnaleźć tabelę oraz zapisane w dokumencie kwoty, lecz aplikacja musi jeszcze powiązać każdą wartość z jej znaczeniem.

Ta różnica ma znaczenie zwłaszcza przy pozycjach faktury. Zachowana tabela pomaga odczytać kolejność komórek, ale nie zamienia automatycznie każdej liczby w nazwane pole używane przez program księgowy. Kod odpowiedzialny za dalsze przetwarzanie musi odróżnić cenę jednostkową od wartości pozycji oraz sumę dokumentu od kwot w jego wierszach.

W przepływie opartym na modelu faktur Azure aplikacja dostaje wynik przypisany do schematu usługi, obejmujący między innymi dane stron transakcji, termin płatności, kwotę należną i pozycje. Może odczytywać te wartości jako pola zamiast szukać ich w całej treści strony. Jeżeli celem jest archiwum z możliwością przeszukiwania pełnego tekstu, przewaga gotowego schematu faktury będzie mniejsza niż przy automatycznym księgowaniu.

Kto odpowiada za schemat i jego zmiany

Mistral oferuje również drogę do nazwanych pól. Funkcja Annotations przyjmuje zdefiniowany przez użytkownika format JSON i może wydobywać z dokumentu wskazane informacje, w tym dane dostawcy oraz kwoty z faktur. W takim porównaniu po jednej stronie jest usługa z własnym schematem przygotowanym przez zespół, a po drugiej model Azure z gotowym schematem pól faktury.

Własny schemat daje miejsce na pola specyficzne dla obiegu firmy. Trzeba jednak ustalić ich znaczenie, typy danych oraz sposób obsługi wartości, których na danej fakturze nie ma. Jeśli dokument zawiera kilka dat lub kilka podobnych kwot, definicja pola powinna wskazywać, którą z nich aplikacja ma przekazać dalej.

Zmiana szablonu u dostawcy może ujawnić błąd w parserze Markdownu albo w regułach przypisywania wartości do własnego schematu. Gotowy model Azure ogranicza pracę nad typowymi polami, lecz nie zwalnia z dopasowania jego wyniku do struktury systemu odbiorczego. W obu przepływach potrzebne są też reguły dla brakujących danych i wartości, które wymagają wyjaśnienia przed zaksięgowaniem.

Polski język i format pliku zależą od wybranego modelu

Dla polskich faktur trzeba sprawdzić obsługę języka w modelu wydobywającym pola, a nie tylko w ogólnej funkcji OCR. Lista języków modelu prebuilt-invoice obejmuje polski dla Polski oraz kod waluty PLN. Wpis na liście oznacza obsługę tych danych; sam w sobie nie przesądza o poprawności odczytu faktury od konkretnego dostawcy.

Mistral obsługuje dokumenty wielojęzyczne, ale rozpoznanie tekstu i przypisanie go do pól to odrębne wyniki. Na fakturze od zagranicznego dostawcy można poprawnie odczytać kwotę, a mimo to przypisać ją do niewłaściwej pozycji lub rodzaju należności. Dlatego znaczenie ma język dokumentów, które rzeczywiście trafiają do firmy, oraz to, czy potrzebna jest ich pełna treść, czy zestaw określonych pól.

Równie ważny jest format wejścia. Mistral OCR przyjmuje między innymi PDF, obrazy, DOCX i PPTX. W Azure modele Read i Layout obsługują także pliki Office, ale ta możliwość nie przechodzi automatycznie na model faktur: dla modeli wstępnie zbudowanych dokumentacja wskazuje PDF i obrazy. Jeśli faktury trafiają jako pliki Office, ten szczegół może wymagać osobnego etapu konwersji w przepływie opartym na modelu faktur.

Za co płaci się przy przetwarzaniu strony

Opublikowane w lipcu 2026 roku zestawienie stawek InvoiceExtractor podaje 4 USD za tysiąc stron podstawowego Mistral OCR, 5 USD za tysiąc stron z Annotations, około 10 USD za tysiąc stron modelu faktur Azure i około 1,50 USD za tysiąc stron modelu Azure Read. Kwota dla modelu faktur Azure jest przybliżona, a stawki dotyczą różnych wyników przetwarzania. Azure Read pokazuje też, dlaczego nie można ogólnie nazwać jednej usługi tańszą bez wskazania konkretnego modelu.

Podstawowy OCR Mistrala może kosztować mniej za stronę niż gotowa ekstrakcja faktury w Azure, lecz nie dostarcza tego samego rezultatu. Do ceny wywołania trzeba doliczyć napisanie parsera pól albo przygotowanie schematu Annotations. Następnie dochodzą walidacja, mapowanie do systemu finansowego i utrzymanie przepływu, gdy zmieniają się dokumenty.

Różnica między stawkami API nie mówi jeszcze, ile będzie kosztować faktura przyjęta bez ręcznej poprawki. Warunkowo, jeśli dwa przepływy przetwarzają tę samą liczbę stron, lecz jeden częściej kieruje dokument do wyjaśnienia, oszczędność na odczycie może zostać pochłonięta przez obsługę wyjątków. To zależność kosztowa, a nie opublikowany wynik testu dokładności tych usług.

Wybór zależy od wyniku, który ma trafić dalej

Dla wyszukiwania w dokumentach i zachowania ich treści sensownym punktem odniesienia jest kompletność odczytu, kolejność tekstu oraz struktura tabel. Dla księgowania miarą staje się poprawność nazwanych pól: numeru faktury, stron transakcji, dat, kwot i pozycji. Porównanie samego Markdownu z gotowym JSON-em faktury miesza te dwa zadania.

Firma, która potrzebuje pól faktury bez definiowania własnego schematu, ma krótszą drogę integracyjną z modelem Azure. Mistral daje większą swobodę przy pełnym odczycie dokumentu i własnym zestawie pól, ale przenosi na zespół decyzje dotyczące schematu oraz jego utrzymania. Przy wyborze dla księgowości sens ma zatem porównanie pełnych przepływów prowadzących do tych samych pól, wraz z liczbą dokumentów wymagających poprawki i czasem potrzebnym na ich obsługę.

Przeczytaj także:

• Faktoring czy kredyt obrotowy? Termin faktury może odwrócić wynik
• ChatGPT czy Perplexity do researchu? Więcej źródeł nie gwarantuje racji
• Cursor czy GitHub Copilot? Tańszy plan nie zawsze oznacza tańsze agenty