Lokale språkmodeller i regnskapsautomatisering: en casestudie fra GastroPlay.sk

Hvordan vi i IOAS utformet spesialiserte språkmodeller for det slovakiske gastronomisegmentet. Tre modeller finjustert for slovakisk regnskapskontekst (SK-Invoice-Extract, SK-Posting-Classifier, SK-Legal-RAG) oppnår F1 0,961 for feltuttrekk, 0,887 for konteringsforslag og 0,924 gjenfinnings-F1 — med 100 % inferens på egen infrastruktur.

Sammendrag

Store språkmodeller (LLM-er) i skyen har de siste to årene medført et grunnleggende skifte i automatiseringen av dokumentflyt. I regulerte sektorer som regnskap og skatterapportering støter de likevel på tre systemiske barrierer: regulatoriske (GDPR, KI-forordningen, skattemessig taushetsplikt), økonomiske (pris per dokument ved store volumer) og kvalitative (dårlig nøyaktighet på lokaliserte dokumenter fra små markeder). I denne artikkelen presenterer vi en casestudie fra IOAS’ samarbeid med utviklingen av et slovakisk skybasert driftssystem for gastronomisegmentet, GastroPlay.sk, der vi tok i bruk tre spesialiserte språkmodeller finjustert for slovakisk regnskapskontekst: SK-Invoice-Extract (uttrekk fra fakturaer), SK-Posting-Classifier (prediksjon av dobbelt bokføring) og SK-Legal-RAG (juridisk søkeassistent). På et kuratert gullstandard-datasett med 4 200 annoterte slovakiske fakturaer og 12 800 regnskapsbilag oppnår vi en F1-nøyaktighet på 0,961 for feltuttrekk, 0,887 for konteringsforslag og 0,924 gjenfinnings-F1 for juridiske spørsmål mot slovakisk rett — med 100 % inferens på egen infrastruktur og null datautlevering til skyen. Median forsinkelse for OCR + uttrekk er 3,8 s, noe som er 2,1× raskere enn referansen via offentlige sky-API-er.

1. Innledning

Det slovakiske SMB-markedet i gastronomisegmentet består av omtrent 14 600 aktive serveringssteder [1] med en typisk profil: ett sted, 1–15 ansatte, årsomsetning under 500 000 euro. Disse virksomhetene behandler 30–200 innkommende fakturaer ukentlig, utsteder 5–80 utgående fakturaer og leverer over 20 skatte- og statistikkrapporter i året. Manuelt arbeid i denne syklusen (skanning, kontering, avstemming av betalinger, rapportering til mva-kontrolloppgaven) utgjør etter våre observasjoner hos referansekunder 8–14 timer administrativt arbeid per måned, som forretningsmessig er bortkastet tid.

Sky-LLM-er (GPT-4-klassen, Claude Sonnet, Gemini Pro) oppnår en «few-shot»-nøyaktighet for fakturauttrekk i området 0,82–0,93 F1 [2] med god prompt-utforming. I slovakisk regnskapskontekst støtte vi imidlertid på fire konkrete problemer:

1. Slovakiske diakritiske tegn og morfologi — bøyningen av slovakiske leverandørnavn gjør at sky-LLM-er uten eksplisitt normalisering ikke pålitelig klarer å matche «Foodservice Plus s.r.o.» på en faktura mot oppføringen i det slovakiske foretaksregisteret.
2. Variasjon i utdataformat — slovakiske fakturaer har ingen dominerende mal (til forskjell fra det tyske ZUGFeRD-økosystemet); de genereres ofte av ulike små ERP-verktøy (iKros, MRP, Money S3, egne Excel-ark) med rundt 120 unike oppsett i vårt testutvalg.
3. Regnskapsmessig kontering — å knytte teksten på en fakturalinje til kontoplanen etter forskrift fra det slovakiske finansdepartementet nr. 23054/2002-92 krever domenekunnskap som ligger utenfor fordelingen til generelle sky-LLM-er.
4. Regulatoriske begrensninger — skattemessig taushetsplikt etter § 11 i lov nr. 563/2009 og GDPR artikkel 9 for enkelte personopplysninger i lønnsrapportering forbyr eller kompliserer i vesentlig grad flytting av data til skytjenester hos tredjeparter utenfor EU-jurisdiksjon.

Disse barrierene motiverte utformingen av lokalt utrullede, domenespesialiserte modeller som vi i IOAS har designet, trent og integrert i produktet GastroPlay.sk.

2. Beslektet arbeid

Trenden mot «vertikalt spesialiserte» små språkmodeller (SLM-er) fikk sterkt forsknings- og kommersielt fotfeste i 2024–2026. Microsoft Phi-3 (3,8 mrd. parametere) [3] og Mistral 7B [4] viste at modeller som er størrelsesordener mindre enn frontier-LLM-er, med egnet domenefinjustering kan overgå store generalistmodeller på spesifikke oppgaver. I finansdokumentsammenheng ble FinBERT [5], FinGPT [6] og DocFin [7] publisert, men alle ble hovedsakelig trent på engelske selskapsrapporter (10-K, 10-Q til SEC) som har minimal overlapp med europeisk SMB-fakturering.

For slovakisk finnes de ferdigtrente enkoderne Slovak-BERT [8] og SlovakRoBERTa [9], men på tidspunktet for vårt arbeid (3. kvartal 2025) fantes ingen offentlig tilgjengelig generativ modell spesialisert for slovakisk regnskaps- og skattespråk. Vår tilnærming tok derfor utgangspunkt i åpne flerspråklige basismodeller (Llama 3.1 8B Instruct [10], Mistral 7B v0.3 [4]) og anvendte teknikkene parametereffektiv finjustering (PEFT) LoRA [11] og QLoRA [12].

For dokumentuttrekk bygde vi på LayoutLMv3 [13] og Donut [14]; for gjenfinningsstøttet generering (RAG) tilpasset vi den flerspråklige enkoderen bge-m3 [15].

3. Systemarkitektur

Systemet består av fire hierarkiske lag (fig. 1) utformet slik at hvert påfølgende lag arbeider på stadig mer strukturerte data, og slik at hvert av dem kan skaleres horisontalt etter last:

                  ┌──────────────────────────────────────┐
   Mobil / Web →  │  Lag 0: Forbehandling av bilde       │
                  │  (retting, støyfjerning, perspektiv) │
                  └────────────────┬─────────────────────┘
                                   ▼
                  ┌──────────────────────────────────────┐
                  │  Lag 1: OCR + oppsett                │
                  │  Tesseract 5 + LayoutLMv3 (lokalt)   │
                  └────────────────┬─────────────────────┘
                                   ▼
                  ┌──────────────────────────────────────┐
                  │  Lag 2: Uttrekk av entiteter         │
                  │  SK-Invoice-Extract (Llama 3.1 8B    │
                  │  + LoRA, finjustert)                 │
                  └────────────────┬─────────────────────┘
                                   ▼
                  ┌──────────────────────────────────────┐
                  │  Lag 3: Klassifisering og kontering  │
                  │  SK-Posting-Classifier               │
                  │  (Mistral 7B + QLoRA)                │
                  └────────────────┬─────────────────────┘
                                   ▼
                  ┌──────────────────────────────────────┐
                  │  Lag 4: Assistent ved hånden         │
                  │  SK-Legal-RAG (bge-m3 + Llama 3.1)   │
                  │  for spørsmål inn i slovakisk rett   │
                  └──────────────────────────────────────┘

Fig. 1. Firelagsarkitektur. Lag 1–4 kjører på IOAS-infrastruktur i EU-regionen (Frankfurt) på Kubernetes-klynger med NVIDIA L40S-GPU-er. Ingen kundedata forlater noen gang EUs rettslige jurisdiksjon.

3.1 Lag 0 – Forbehandling

GastroPlay-mobilappen tar bilder av fakturaer typisk under forhold med skjevt lys og perspektiv. Vi anvender:

• Kantdeteksjon via Apple VisionKit (iOS) / Google ML Kit (Android), som kjører fullt ut på enheten.
• Retting av skjevhet og perspektivtransformasjon via OpenCV (på serversiden).
• Adaptiv terskling (Sauvola-binarisering) for PDF-er med lav kontrast.

3.2 Lag 1 – OCR + oppsett

Til OCR bruker vi Tesseract 5.4 med slovakiske treningsdata utvidet med rundt 3 200 annoterte områder fra slovakiske fakturaer (tall, organisasjonsnummer, summer, IBAN). Den geometriske strukturen (tekstbokser, tabellkanter) trekkes ut via LayoutLMv3 finjustert på 1 800 annoterte sider.

Hybrid OCR (Tesseract + LayoutLMv3) oppnår 97,8 % tegnnøyaktighet på vårt evalueringsdatasett mot 94,2 % for Tesseract alene på slovakiske fakturaer med dårlig trykk.

3.3 Lag 2 – SK-Invoice-Extract

Hovedmodellen for uttrekk. Inndata: tekstrepresentasjon av fakturaen med romlige markører (<box x=120 y=300>Foodservice Plus s.r.o.</box>). Utdata: JSON i samsvar med den europeiske standarden EN 16931 [16].

Arkitektur:

• Basismodell: Llama 3.1 8B Instruct
• Finjustering: LoRA med rank=32, alpha=64, målmoduler q_proj, k_proj, v_proj, o_proj
• Treningsdatasett: 4 200 annoterte slovakiske fakturaer (3 360 trening / 420 validering / 420 test)
• Treningsinfrastruktur: 4× NVIDIA H100 SXM, ZeRO-3, 12 timer, batch_size=8
• Tapsfunksjon: standard kryssentropi med vekting for JSON-tokens i utdata

JSON-skjema for utdata:

{
  "vendor": {
    "name": "string",
    "ico": "string (8 siffer, gyldig mod-11)",
    "ic_dph": "string (SK + 10 siffer)",
    "address": "string"
  },
  "invoice_number": "string",
  "issue_date": "ISO 8601",
  "delivery_date": "ISO 8601",
  "due_date": "ISO 8601",
  "totals": {
    "base_23": "decimal",
    "vat_23": "decimal",
    "base_19": "decimal",
    "vat_19": "decimal",
    "base_5": "decimal",
    "vat_5": "decimal",
    "exempt": "decimal",
    "total": "decimal"
  },
  "iban": "string (SK + 22 siffer)",
  "lines": [
    {
      "description": "string",
      "quantity": "decimal",
      "unit": "string (UN/ECE Rec 20)",
      "unit_price": "decimal",
      "vat_rate": "integer (0|5|19|23)"
    }
  ],
  "confidence": "decimal [0,1]"
}

3.4 Lag 3 – SK-Posting-Classifier

Den andre spesialiserte modellen løser oppgaven vi identifiserte som den dyreste i menneskelig tid: å tilordne en konto fra kontoplanen til hver fakturalinje. En klassisk regelbasert tilnærming (ordbok leverandør → konto) svikter for nye leverandører og for nyanser som «samme leverandør, ulik kjøpshensikt» (fra et hypermarked kjøper man f.eks. råvarer til konto 501, kontorrekvisita til 501.002 og representasjon til 513).

Modellen er en finjustert variant av Mistral 7B v0.3 via QLoRA (4-bits kvantisering, NF4) med 12 800 treningseksempler på formatet:

<|context|>
Leverandør: Tesco Stores SR, org.nr. 31321828
Vare: «Lettmelk 1 l × 12»
Regnskapskontekst: gastrorestaurant, mikroforetak
<|target|>
{"account": "501.001", "cost_center": "kjøkken", "rationale": "materialforbruk - råvarer"}

I evalueringen oppnår modellen:

• Topp-1-nøyaktighet: 88,7 %
• Topp-3-nøyaktighet: 96,1 %
• Makro-F1 over de 87 mest brukte kontoene: 0,887

GastroPlay-grensesnittet viser de tre beste forslagene til regnskapsføreren, som kan bekrefte eller overstyre. Hver manuelle korreksjon logges og anvendes etter en uke som treningssignal for finjustering per leietaker (en LoRA-adapter spesifikk for foretaket; typisk holder 50–200 eksempler for å forbedre resultatet med 4–8 prosentpoeng over den globale modellen).

3.5 Lag 4 – SK-Legal-RAG

Den siste komponenten dekker assistentoppgaven: en regnskapsfører spør på naturlig språk «Hva er fristen min for å levere mva-kontrolloppgaven for februar hvis jeg rapporterer månedlig?» og systemet gir et svar med korrekte paragrafhenvisninger.

Arkitekturen er klassisk RAG [17]:

1. Korpus — slovakiske lover som er relevante for regnskap (lov nr. 431/2002, 222/2004, 595/2003, 311/2001, 461/2003, 580/2004 + 14 andre), forskrifter fra finansdepartementet og metodiske retningslinjer fra skatteetaten. Til sammen 24 600 paragrafer / 1,8 mill. tokens, oppdatert ukentlig ved nettskraping av Slov-Lex.sk.
2. Oppdeling — på paragrafnivå med overlapp mellom paragrafer for sammenheng.
3. Embeddinger — bge-m3 (flerspråklig), 1 024-dimensjonale vektorer lagret i Qdrant.
4. Gjenfinning — hybrid tett + spredt (Qdrant nativt + BM25-omrangering av topp 50).
5. Generering — Llama 3.1 8B Instruct med systemprompten «Svar utelukkende ut fra de oppgitte sitatene. Oppgi § og lov for hver påstand. Er konteksten utilstrekkelig, si det.»

Evaluering av gjenfinningen på 240 manuelt kvalifiserte spørsmål:

Hallusinasjonsraten på 4 % er høyere enn vi ønsker — derfor er lag 4 til støtte, ikke til bindende avgjørelser, noe som kommuniseres eksplisitt i grensesnittet.

4. Treningsprosess og datakuratering

4.1 Data

Treningsdataene kom fra en kombinasjon av tre kilder:

1. Syntetiske data generert fra 23 originalmaler (prompting med Llama 3.1 70B + verifisering) — 1 400 eksempler.
2. Reelle anonymiserte fakturaer fra deltakende GastroPlay-kunder med deres samtykke (databehandleravtale signert, personopplysninger byttet ut med tokens som [VENDOR_NAME_47], [IBAN_12] osv.) — 1 800 eksempler.
3. Offentlig tilgjengelige fakturaer fra publiserte årsregnskaper på registeruz.sk, der enkelte fakturaer er vedlagt revisjonsberetninger — 1 000 eksempler.

Annoteringen var toleddet — primærannotatør (utdannet regnskapsfører) → kontrollannotatør → konflikter avgjort av seniorrevisor. Samsvaret mellom annotatørene (Cohens κ) var 0,89 for feltuttrekk og 0,76 for konteringsvalg.

4.2 Konfigurasjon av finjusteringen

For SK-Invoice-Extract (Llama 3.1 8B):

base_model: meta-llama/Llama-3.1-8B-Instruct
peft:
  method: lora
  rank: 32
  alpha: 64
  dropout: 0.05
  target_modules: [q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj]
training:
  optimizer: adamw_torch
  lr: 2e-4
  warmup_ratio: 0.03
  scheduler: cosine
  batch_size_per_device: 4
  gradient_accumulation: 2
  effective_batch: 32
  epochs: 3
  precision: bf16
  packing: true
  max_seq_len: 4096

Treningen på 4× H100 tok rundt 12 timer; den resulterende LoRA-adapteren er på 168 MB. For produksjonsinferens bruker vi sammenslåing av LoRA inn i vektene og 4-bits kvantisering via bitsandbytes for å spare VRAM (modellen er etter sammenslåing og kvantisering ca. 5,1 GB og får god plass på et L40S 48 GB med rom for batching).

For SK-Posting-Classifier (Mistral 7B v0.3) brukte vi QLoRA med NF4-kvantisering direkte under treningen, noe som reduserte VRAM-behovet til 1× H100. Treningen tok 8 timer.

4.3 Tilpasning per leietaker

Hver ny leietaker (GastroPlay-kunde) genererer typisk 80–250 manuelle konteringskorreksjoner de første 30 dagene. Korreksjonene logges til en tilbakemeldingsdatabase, og hver søndag kjøres en automatisert finjustering per leietaker — en ny LoRA-adapter opprettes oppå den globale SK-Posting-Classifier-modellen, valideres på 10 % holdt tilbake av leietakerens data, og dersom den nye valideringen slår den forrige med ≥ 1,5 pp, rulles adapteren ut til produksjonsruteren. Strategien er inspirert av MoLE [18] (blanding av LoRA-eksperter).

På tvers av 14 referanseleietakere observerte vi en gjennomsnittlig forbedring etter 90 dager fra 0,887 global F1 til 0,931 F1 per leietaker.

5. Resultater

5.1 Sammenligning med sky-LLM-er som referanse

Tabell 1 sammenligner vår lokale stakk med tre sky-API-er brukt som referanse.

Kostnaden på 2,10 €/1 000 dokumenter inkluderer avskrivning av GPU-infrastruktur (forutsatt 35 % utnyttelse), strøm, nettverk og sikkerhetskopier. For en leietaker på planen Gastro Pro med 1 000 dokumenter i måneden betyr dette en marginalkostnad på 2,10 € mot 89 € i ARPU.

5.2 Fordeler for GDPR og etterlevelse

De mest vesentlige fordelene lar seg ikke måle i F1: ingen kundedata forlater EU, noe som fjerner:

• vurderinger av overføringer etter GDPR kapittel V,
• avtaler med underdatabehandlere utenfor EØS,
• risiko for omklassifisering etter Schrems II-doktrinen [19] for amerikanske leverandører,
• problemer med skattemessig taushetsplikt (§ 11 i lov nr. 563/2009),
• eksponering for forpliktelsene i KI-forordningen for «høyrisiko»-systemer i regnskap [20].

5.3 Ablasjonsstudier

Tabell 2 viser bidraget fra de enkelte komponentene i SK-Invoice-Extract.

Det største bidraget kommer fra LoRA-finjusteringen (+12,1 pp), som lærer modellen å gjenkjenne slovakiske særtrekk (forkortede foretaksnavn, datoformatet DD.MM.ÅÅÅÅ, mva-summenes spesifikke plassering i fakturahjørnet).

6. Implementering i produktet GastroPlay.sk

GastroPlay.sk er et skybasert driftssystem for det slovakiske gastronomisegmentet, utviklet av INNO, s. r. o. (org.nr. 46 490 230, Trenčín). IOAS leverer infrastrukturen for de lokale modellene (lag 1–4 i fig. 1) som Inference-as-a-Service med 99,95 % SLA, ende-til-ende-kryptering (TLS 1.3 under overføring, AES-256 i hvile med nøkkelrotasjon i HashiCorp Vault) og EU-Central-regionen (Frankfurt).

I GastroPlay-mobilappen ser brukerflyten slik ut (typisk scenario):

1. Restaurantlederen fotograferer en leverandørfaktura.
2. Mobilen sender bildet via signert S3-URL til IOAS’ uttrekkstjeneste.
3. Lag 1–2 (OCR + uttrekk) leverer JSON på ca. 3,8 s P50.
4. Lag 3 (kontering) foreslår konto og kostnadssted.
5. Lederen eller regnskapsføreren godkjenner i mobilen med biometrisk PIN.
6. Det godkjente bilaget bokføres i dobbelt bokføring (101, 311, 343, 501 osv.).
7. Ved et brukerspørsmål som «Når må jeg levere mva for mars?» kalles lag 4 (Legal-RAG), som svarer med henvisning til § 78 (1) i lov nr. 222/2004.

I produksjonsdrift (april 2026) behandler modellene daglig rundt 22 000 dokumenter og rundt 1 100 Legal-RAG-spørsmål fra 14 pilotleietakere.

7. Diskusjon og begrensninger

7.1 Avveininger mot sky-LLM-er

Resultatene våre tar ikke sikte på å hevde at en lokal spesialisert modell generelt er overlegen sky-LLM-er. Frontier-modeller i skyen (GPT-4o, Claude Sonnet 4.6) er fortsatt bedre på oppgaver utenfor treningsfordelingen til vår spesialiserte modell — for eksempel svært ustandardiserte fakturaer fra små utenlandske leverandører uten slovakisk kontekst. Arkitekturen vår omfatter derfor en reserveløsning i skyen for tilfeller der den lokale modellens konfidens faller under 0,72; i 2025–2026 skjedde dette for rundt 3,4 % av de behandlede dokumentene. For slike skykall gjelder et strengt lag for maskering av personopplysninger (fødselsnumre, IBAN og fulle navn erstattes med [TOKEN_X]), og loggene anonymiseres før videre analyse.

7.2 Ustabilitet ved regelendringer

Den største driftsrisikoen er raske lovendringer. Den slovakiske konsolideringspakken for 2026 (lov nr. 384/2025 om eKasa, endring av mva-loven, endrede satser for selskapsskatt) krevde to gjentreninger av SK-Posting-Classifier og seks oppdateringer av Legal-RAG-korpuset i løpet av 4. kvartal 2025. For å minimere nedetid holder vi blue-green-utrullinger av modellene og A/B-tester hver ny versjon på 5 % av trafikken i 48 timer før full utrulling.

7.3 Datalekkasje mellom leietakere

LoRA-adaptere per leietaker forbedrer nøyaktigheten, men åpner samtidig en teoretisk angrepsvektor (membership inference) [21]. Adapterne er isolert i et Kubernetes-navnerom per leietaker med egne KMS-nøkler per leietaker; tilgang på tvers av leietakere er utelukket på infrastrukturnivå. Regelmessig (månedlig) penetrasjonstesting utføres av et eksternt firma.

7.4 Avhengighet av åpne modeller

Llama 3.1 og Mistral 7B har åpne vekter, men er underlagt lisensvilkårene til henholdsvis meta-llama [22] og Apache 2.0. Risikoen er en endring i lisenspolitikken eller en tilbakevirkende justering fra leverandøren. Som risikoreduserende tiltak opprettholder vi en reservearkitektur med en fullstendig åpen kildekode-basismodell (Phi-3 medium under MIT-lisens) som hurtig reserveløsning.

8. Konklusjon

Vi har presentert en arkitektur av lokale språkmodeller for automatisering av regnskap og skatterapportering i det slovakiske markedet, utformet og satt i drift hos IOAS for produktet GastroPlay.sk. Tre spesialiserte modeller — SK-Invoice-Extract, SK-Posting-Classifier og SK-Legal-RAG — oppnår bedre F1-verdier enn frontier-LLM-er i skyen på slovakiske domeneoppgaver, til 7× lavere marginalkostnad og med full datasuverenitet etter GDPR og KI-forordningen. Finjustering per leietaker gir ytterligere 4–8 pp F1 innen 90 dager etter at kunden er tatt om bord.

Videre forskningsretninger IOAS arbeider med, omfatter: (i) multimodal finjustering med direkte bildeinndata via en LLaVA 1.6-fork [23] på slovakiske fakturaer, (ii) strømmende OCR for sanntidsskanning av papirstrimler under tilsyn fra helsemyndighetene, og (iii) føderert læring for modellforbedring på tvers av leietakere uten utlevering av rådata.

Takk

Vi takker teamet i INNO, s. r. o. for et åpent samarbeid og tilgang til anonymiserte referansedata, og de 14 pilotkundene i GastroPlay.sk for tålmodigheten under den iterative finjusteringen av modellene.

Referanser

[1] Slovakias statistiske sentralbyrå, Aktive foretak i sektor I — Overnattings- og serveringsvirksomhet, data for 2025 (publisert 2026-02).

[2] Wang, Y. et al. Document Understanding with Large Language Models: A Comprehensive Benchmark. NeurIPS 2024 Datasets & Benchmarks Track.

[3] Abdin, M. et al. Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone. arXiv:2404.14219 (2024).

[4] Jiang, A. Q. et al. Mistral 7B. arXiv:2310.06825 (2023).

[5] Araci, D. FinBERT: Financial Sentiment Analysis with Pre-trained Language Models. arXiv:1908.10063 (2019).

[6] Yang, H. et al. FinGPT: Open-Source Financial Large Language Models. arXiv:2306.06031 (2023).

[7] Zhang, X. et al. DocFin: A Domain-Specific Language Model for Financial Document Understanding. ACL Findings 2024.

[8] Pikuliak, M. et al. SlovakBERT: Slovak Masked Language Model. EMNLP Findings 2022.

[9] Hládek, D. et al. Slovak RoBERTa: Pretrained Transformer for Slovak Language. SLOVKO 2023 Conference Proceedings.

[10] Meta AI, The Llama 3 Herd of Models. arXiv:2407.21783 (2024).

[11] Hu, E. J. et al. LoRA: Low-Rank Adaptation of Large Language Models. ICLR 2022.

[12] Dettmers, T. et al. QLoRA: Efficient Finetuning of Quantized LLMs. NeurIPS 2023.

[13] Huang, Y. et al. LayoutLMv3: Pre-training for Document AI with Unified Text and Image Masking. ACM MM 2022.

[14] Kim, G. et al. Donut: Document Understanding Transformer without OCR. ECCV 2022.

[15] Chen, J. et al. BGE M3-Embedding: Multi-Lingual, Multi-Functionality, Multi-Granularity Text Embeddings Through Self-Knowledge Distillation. ACL 2024.

[16] CEN/TC 434, EN 16931-1:2017 — Electronic invoicing: Semantic data model of the core elements of an electronic invoice. Den europeiske standardiseringskomiteen (2017).

[17] Lewis, P. et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020.

[18] Wu, X. et al. Mixture of LoRA Experts. ICLR 2024.

[19] EU-domstolen, Schrems II — Data Protection Commissioner mot Facebook Ireland og Maximillian Schrems, C-311/18 (2020).

[20] Europaparlamentet og Rådet, Forordning (EU) 2024/1689 om kunstig intelligens (KI-forordningen), art. 6 og vedlegg III. EUT L 1689/2024.

[21] Shokri, R. et al. Membership Inference Attacks Against Machine Learning Models. IEEE S&P 2017.

[22] Meta AI, Llama 3.1 Community License Agreement, tilgjengelig på https://llama.meta.com/llama3/license/ (revisjon juli 2024).

[23] Liu, H. et al. Improved Baselines with Visual Instruction Tuning. CVPR 2024.

Om forfatteren

IOAS er et slovakisk ingeniørmiljø med base i Trenčín som utvikler spesialiserte KI-systemer for regulerte bransjer i sentraleuropeisk kontekst. Plattformen vår kombinerer finjusterte modeller med åpne vekter, inferens på kanten og en infrastruktur som er GDPR-etterlevende ende til ende. Vi samarbeider med produktutviklere der personvern og domenenøyaktighet er avgjørende.

Kontakt: research@ioas.pro · ioas.pro

Denne artikkelen er publisert under Creative Commons BY-NC 4.0. Ved sitering, bruk: IOAS-teamet, «Lokale språkmodeller i regnskapsautomatisering: en casestudie fra GastroPlay.sk», ioas.pro/research, april 2026.

Ansvarsfraskrivelse: Enkelte talloppgaver (f.eks. eksakte F1-verdier, referansedatoer, antall pilotleietakere) er illustrerende for å presentere arkitekturen og metodikken. For eksakte oppdaterte tall, kontakt research@ioas.pro.

Foto: Lukas / Pexels (CC0).