AP Exception Desk: AI-ul investighează excepțiile din facturi, omul decide

Echipele de contabilitate a furnizorilor (accounts payable) din companiile de distribuție petrec o bună parte din zi cu facturi care nu se potrivesc cu comanda de achiziție. AP Exception Desk este sistemul pe care l-am construit ca să preia munca de investigație. Citește facturile furnizorilor și le compară cu comenzile de achiziție și recepțiile de marfă. Când ceva nu se potrivește, un agent AI află de ce și pregătește pasul următor. Un contabil aprobă, respinge sau escaladează fiecare propunere, iar fiecare pas rămâne într-un jurnal de audit care nu poate fi modificat pe ascuns.

Provocarea: excepțiile din facturi consumă timp și atrag frauda

O factură de la furnizor ar trebui să corespundă cu două documente: comanda de achiziție (ce s-a comandat și la ce preț) și recepțiile (ce a ajuns de fapt). Când nu corespund, factura devine o excepție. Cineva trebuie să afle de ce, să contacteze cumpărătorul sau furnizorul și să decidă ce urmează. Munca e manuală și lentă, greșelile costă bani, iar unele excepții sunt tentative de fraudă.

Pentru distribuitorii de mărime medie din țările baltice, excepțiile sunt rutină, nu cazuri rare:

• Majoritatea furnizorilor sunt din străinătate, așa că fiecare factură ridică o întrebare de TVA: TVA leton, taxare inversă UE sau import.
• Marfa sosește pe bucăți sau deteriorată, așa că facturile ajung adesea înaintea recepțiilor.
• Listele de prețuri ale furnizorilor se schimbă în timpul anului, iar comenzile păstrează prețul vechi.
• Facturile vin pe email de la mulți expeditori, ceea ce face reală frauda cu „date bancare noi” și domeniile care imită expeditorul.
• O echipă mică de contabili se ocupă de toate excepțiile, deci contează timpul pe caz și escaladarea corectă.

De aici au rezultat cinci cerințe pentru sistem:

1. 1Să detecteze fiecare diferență, la fel de fiecare dată.
2. 2Să reducă timpul pe care un contabil îl petrece investigând fiecare excepție.
3. 3Să oprească frauda înainte ca banii să plece din companie.
4. 4Să lase omul să decidă tot ce are consecințe.
5. 5Să păstreze evidența: cine a decis ce și de ce.

Soluția: AI-ul investighează, omul decide

Am împărțit munca după ce face fiecare parte cel mai bine. Codul citește datele structurate și face toate calculele. Agentul AI face citirea și raționamentul pe care un contabil le-ar face altfel de mână. Un om ia fiecare decizie care are consecințe.

Citirea facturilor: exact unde se poate, AI unde e nevoie

Facturile electronice structurate (Peppol BIS / EN 16931 UBL, UN/CEFACT CII și Factur-X / ZUGFeRD) sunt citite exact, fără model. Doar PDF-urile fără date de factură electronică încorporate, inclusiv scanările, merg la un model vizual. O citire care nu trece validarea primește o nouă încercare, împreună cu verificările eșuate.

Fiecare citire e apoi validată. Liniile trebuie să dea subtotalul, TVA-ul și totalul, cifra de control a IBAN-ului trebuie să fie corectă, iar codul de TVA și datele trebuie să fie valide. În loc de un procent de încredere, fiecare câmp primește unul din trei statusuri: verificat (o verificare independentă îl confirmă), neverificat (citit, dar nimic nu îl confirmă) sau eșuat. Contabilul vede fiecare câmp lângă documentul original și știe exact ce să verifice.

Potrivire deterministă în trei pași

Motorul de potrivire e cod Python simplu, cu aritmetică zecimală exactă. Împerechează liniile facturii cu liniile comenzii (după cod, apoi descriere, apoi preț), calculează diferențele de preț și cantitate, ține evidența cantităților deja facturate, detectează duplicatele și verifică TVA-ul după țara furnizorului. Implicit, o diferență de preț e semnalată doar când depășește și 2%, și 10 €. Toleranța poate fi setată pe furnizor.

Un agent AI care investighează, dar nu poate acționa

Pentru fiecare excepție, agentul strânge dovezi prin unelte doar de citire: factura, comanda, recepțiile, condițiile contractuale, fișa furnizorului, facturile lui anterioare și firul de emailuri. Întoarce un diagnostic pe înțeles, până la zece dovezi care citează fiecare apelul de unealtă din care provin, o etichetă de încredere și o singură acțiune propusă, dintre cele permise pentru acel tip de excepție.

Codul verifică răspunsul înainte să-l vadă un om. Fiecare cifră citată de agent e comparată cu sursele ei (detalii mai jos). Regulile pot face un caz doar mai prudent: o acțiune în afara celor permise devine escaladare, iar posibila fraudă și cazurile cu risc mare ajung mereu la un om.

Aceeași împărțire (modelul citește și redactează, codul aplică regulile, omul aprobă) funcționează în multe procese administrative. Așa abordăm, în general, automatizarea cu AI.

Verificări antifraudă pe care AI-ul nu le poate anula

Motorul de potrivire verifică șapte semnale de risc: un cont bancar schimbat, un IBAN invalid, un domeniu de expeditor care nu corespunde furnizorului, un domeniu care îl imită, termene de plată scurtate, un limbaj de urgență și o sumă neobișnuită. Oricare dintre ele face cazul cu risc mare, iar nimic din ce rulează după, nici agentul, nu poate elimina acest marcaj.

Datele bancare citite de pe o factură nu suprascriu niciodată fișa furnizorului. Schimbarea contului bancar e o acțiune separată, verificată, care păstrează contul vechi în evidență. Nici răspunsul pe email al unui furnizor nu poate închide un caz cu date bancare: acestea se verifică telefonic, cu o persoană de contact cunoscută.

Emailuri de urmărire, trimise o singură dată

Emailurile aprobate pleacă din căsuța departamentului către cumpărător sau furnizor. Destinatarul vine mereu din datele de referință, niciodată de la model. Dacă nu răspunde nimeni, după cinci zile pleacă memento-uri cu text fix, iar după două memento-uri cazul e escaladat la managerul departamentului.

Răspunsurile sunt legate de cazul lor, ignorate dacă vin de pe alt domeniu decât cel căruia i-am scris, filtrate de un model ieftin și date înapoi agentului. Agentul poate propune închiderea cazului, dar închiderea tot are nevoie de aprobarea unui om.

Un istoric de audit care nu poate fi falsificat

Fiecare pas e scris într-un jurnal de audit în care se poate doar adăuga. Hash-ul fiecărei intrări acoperă conținutul ei și intrarea anterioară, așa că editarea sau ștergerea unui rând rupe lanțul, iar un trigger din baza de date respinge modificările. Pentru fiecare factură, o vizualizare a fluxului arată ce s-a întâmplat și cine a făcut-o: AI-ul, un om sau sistemul.

Arhitectura tehnică

Sistemul are două părți: un backend Python cu API-ul, motorul de potrivire, agentul, fluxul de lucru și un proces care rulează joburile în fundal, și o consolă Next.js pentru contabili. PostgreSQL păstrează datele de business, jurnalul de audit, coada de joburi și starea fluxurilor.

Agent

O buclă de agent proprie în loc de un framework, cu un buget pe investigație (12 pași, 300k tokeni, 1 €, 300 de secunde) și apeluri de unelte în paralel. Când bugetul se termină sau un model cade, cazul ajunge la un om în loc să se blocheze.

Alegerea modelului

Fiecare apel trece prin LiteLLM, așa că modelul e o setare: Anthropic Claude, OpenAI, Google Gemini, OpenRouter sau modele locale prin Ollama. Citirea, investigația și filtrarea răspunsurilor au fiecare modelul lor, cu rezerve pentru limite de cerere și întreruperi.

Flux de lucru

LangGraph rulează fluxul cazurilor, cu starea salvată în PostgreSQL, așa că un caz poate aștepta zile întregi un om sau un furnizor și continuă de unde a rămas. Baza de date rămâne sursa adevărului.

Joburi în fundal

Un outbox tranzacțional: efectele sunt salvate ca joburi în aceeași tranzacție cu decizia, preluate cu o rezervare temporară, reîncercate treptat și deduplicate cu chei de idempotență.

Monitorizare

Fiecare rulare AI e urmărită în Langfuse găzduit intern (pași, tokeni, cost și latență), cu IBAN-urile și adresele de email mascate.

Integrarea cu ERP-ul

Comenzile și recepțiile se află în ERP-ul clientului, cum ar fi SAP Business One, Microsoft Dynamics sau Visma. Conectarea lui e primul pas al fiecărei implementări și un proiect tipic de integrare.

Decizii de inginerie

Fără AI în calculul banilor

Modelele de limbaj pot greși la aritmetică, iar o verificare de plată trebuie să dea mereu același rezultat și să poată fi explicată unui auditor. Așa că fiecare calcul e cod determinist cu aritmetică zecimală, acoperit de teste bazate pe proprietăți. AI-ul citește și explică. Nu decide niciodată dacă cifrele se potrivesc.

Cifrele agentului se verifică, nu se iau pe încredere

Un model poate da o cifră care pare corectă, dar nu există, iar a-i cere să fie atent nu rezolvă asta. În schimb, codul verifică fiecare sumă, procent și număr de document citat de agent, comparându-l cu rezultatul uneltei invocate. O verificare eșuată primește o nouă încercare. După aceea, cazul e marcat pentru un om.

Textul furnizorilor nu e de încredere

Facturile și emailurile vin din afara companiei, așa că instrucțiunile ascunse în ele (prompt injection) sunt o cale reală de atac. Textul furnizorilor ajunge la model ca date, niciodată ca instrucțiuni, iar destinatarii emailurilor vin din datele de referință. Suita de evaluare include instrucțiuni injectate atât într-un email, cât și într-o linie de factură.

Efecte executate o singură dată

Un dublu-clic, o reîncercare sau un proces căzut nu trebuie să trimită două emailuri sau să aplice o decizie de două ori. Deciziile au o cheie de idempotență și o verificare de versiune. Emailurile sunt salvate cu un Message-ID fix înainte de trimitere, așa că o retrimitere după o cădere e recunoscută ca același mesaj.

Rezultate

Măsurăm sistemul cu suite de teste și evaluare cu răspunsuri cunoscute. Rezultatele actuale:

• Evaluarea investigațiilor: 22 de tipuri de cazuri sintetice cu răspuns cunoscut, de la potriviri curate la fiecare tip de excepție, fraudă și prompt injection. Potrivire corectă în 22 din 22, acțiunile agentului corecte în 15 din 15 și 0 încălcări de siguranță.
• Evaluarea citirii: 35 de facturi cunoscute în cinci formate (UBL, CII, Factur-X, PDF și scanări), comparate câmp cu câmp. Pragul: niciun câmp marcat ca verificat nu are voie să fie greșit.
• 272 de teste automate pentru backend, cu verificarea tipurilor și linting trecute pentru backend și consolă.

Pentru un contabil, munca pornește acum de la un diagnostic cu surse și un email pregătit, cu decizia luată direct pe pagina facturii, nu de la un ecran gol și trei documente de comparat manual.

Ce urmează

Sistemul funcționează cap-coadă, de la factura încărcată până la ultimul email. Urmează în plan: conturile de utilizator și aprobarea în patru ochi pentru deciziile cu risc mare, conectarea la ERP, un panou cu volumul excepțiilor, timpii de rezolvare și costul AI, și memoria furnizorilor, ca agentul să învețe din cazuri similare.

Întrebări de la echipele financiare

Poate AI-ul să aprobe sau să plătească o factură?

Nu. Agentul doar citește și propune. Orice acțiune care iese din sistem are nevoie de aprobarea unui om, iar posibila fraudă nu e rezolvată niciodată automat.

Funcționează cu facturi electronice?

Da. Facturile electronice UBL, CII și Factur-X / ZUGFeRD sunt citite exact, fără model. Scanările și celelalte PDF-uri merg la un model vizual și sunt verificate câmp cu câmp.

Putem vedea cine a decis ce?

Da. Fiecare pas, făcut de AI, de un om sau de sistem, e scris într-un jurnal de audit în care se poate doar adăuga, iar fiecare factură are o vizualizare cu istoricul complet.

Poate rula AI-ul pe serverele noastre?

Da. Modelul e o setare, iar modelele locale prin Ollama sunt suportate pentru datele care trebuie să rămână în companie.

Dacă echipa ta de contabilitate își petrece zilele urmărind facturi care nu se potrivesc, povestește-ne despre procesul tău de facturare. Îți spunem sincer ce am automatiza și ce ar trebui să rămână la un om.