AI Enterprise SolutionsFinalistGPT & Claude

Muhasib+ — AI that checks e-invoices against 1C before the VAT return

User: accountants at Azerbaijani SMEs and accounting outsourcing firms. Problem: before every VAT (ƏDV) return they must match each e-invoice on e-taxes.gov.az to a purchase in 1C. They never line up cleanly: supplier names differ (Latin, Cyrillic, English, abbreviations), 1C uses internal numbers, invoices are split, amounts and VÖENs are mistyped. Today this is VLOOKUP plus checking by eye, for hours. A missed mismatch means VAT credit lost, rejected or claimed in the wrong month. On our labelled month, VLOOKUP got only 23% of records right. Solution: upload both exports. Every record is paired or flagged (amount/VAT, VÖEN, wrong period, missing, duplicate) with evidence and a confidence score. AI handles only what rules can't (19 of 144 invoices, 4 requests per month) and writes an Azerbaijani explanation and a supplier email draft. The accountant approves or rejects each finding; nothing is sent automatically. Outcome: 23% → 99.0% correct, 0 missed discrepancies; real company month 24% → 96.6%. Feasibility: only two existing exports, no integration; AI cost $0 on the free tier. Next step: 4-week pilot with one Baku accounting firm.

Open the demo Video GitHub

Preliminary score

86.5/ 100Outstandingaverage of 2 judges

Value for the user22.5 / 25
A specific problem and a clear outcome from solving it.
Prototype and use of AI26.0 / 30
A working core scenario, and what AI actually contributes to the result.
Quality testing18.0 / 20
Tests, examples of failures, and comparison with the current approach.
Feasibility13.0 / 15
Data requirements, running costs and a clear next step.
Originality7.0 / 10
A meaningful difference from common solutions.

A finalist: the live jury scored it 77.0 / 100 on stage.

What the judges wrote

Claude Opus 5.5Preliminary86/100
Strengths
Your problem is sharply defined: Azerbaijani accountants reconciling e-taxes.gov.az e-invoices against 1C before the ƏDV return, with concrete failure modes such as transliterated names, internal ПТ numbers and split invoices. Your hybrid design is well reasoned. Rules and fuzzy matching do most of the work, and the LLM handles only the 19 leftover invoices in 4 batched requests, behind guardrails for low confidence, invented IDs, outages and doc_conflict, all covered by tests. Your evaluation is exemplary for a hackathon: a VLOOKUP baseline, an ablation of rules versus hybrid, 10 generated seeds, and a held-out real company month (70.7% → 96.6%). You also report named failures such as C0155 → P0037 and the split-invoice mispairing, along with the fixes they led to.
To improve
Run the hybrid method on all 10 generated months and on test sets with several errors per case, so the 99.0% figure has a spread rather than a single point. Your 18 h → 4 h time saving is still an assumption-based estimate; in the pilot, time real accountants on the same month with and without the tool. One real month of 58 records is a thin base, so collect a few more labelled real months across different firms before freezing the confidence thresholds. Spell out how the 1C and e-taxes export columns will be mapped when different firms use different 1C configurations.
GPT-6 AstraPreliminary87/100
Strengths
Your project addresses a precise Azerbaijani accounting workflow, with evidence-backed findings, downloadable reports and timestamped human review. Your rules-versus-hybrid comparison isolates AI's contribution, including the reported improvement from 70.7% to 96.6% on a small held-out real month. Your disclosed wrong pairing, failure-driven guardrails and 51 offline tests make the validation unusually concrete and transparent.
To improve
Your next evaluation should run the hybrid across all ten generated months and additional untouched real months containing compound errors, separating incorrect reconciliation from merely avoiding an OK label. Your pilot should measure review time and errors against the complete Excel-plus-manual workflow, since VLOOKUP alone is not the full baseline. Before expanding to more client ledgers, document external-provider data retention and access controls, and validate costs and quotas at accounting-firm scale.

The team

Hüseyn İsayev
developer
Huseyn Azimzade
data
Yunis AllahverdiLead
data
Madina Jafarova
designer
Zahra Rahmanli
data

Disclosure

Required by the rules. Judges verify it against the repository.

Models: Groq openai/gpt-oss-120b (free tier): used for all reported AI results, only on records the rules cannot pair. Google Gemini flash (free tier): earlier run. Claude and OpenAI GPT are supported in the code but not used for the reported results. Claude (Anthropic, via Claude Code) was used as a coding assistant.
Data: Synthetic labelled test months generated by generate_data.py (seed 42 + 10 seeds, errors injected so the correct answer is known). One real month (58 records) from an Azerbaijani company, used with the owner's permission; company name withheld. For the hybrid run its unresolved records were sent to the Groq API. Used only as a held-out test, never for tuning, not in the repository.
Components: Python, pandas, rapidfuzz, Streamlit, openpyxl, openai SDK (to call Groq), google-genai, anthropic, pytest
Built during the event: Confirmed

Quality testing

Tested: 3 methods on one labelled synthetic month (307 records, injected errors): VLOOKUP (today's Excel way) → rules + fuzzy (no AI) → hybrid (rules + AI on leftovers only). Realistic version (1C comments typed like real accountants: often blank or generic): - Accuracy: 23.1% → 94.8% → 99.0% - Alias names: 0 → 56 → 62/62 - Split invoices: 3 → 39 → 45/45 - False alarms: 186 → 12 → 0 - Missed discrepancies: 0 for all - AI requests per month: 4 Robustness: - 10 generated months, rules only: 87.7–94.8%, 0 wrong pairings, 0 missed. Hybrid not yet run on all 10. - Real company month (58 records, never tuned on): 24.1% → 70.7% → 96.6%, 0 missed. This is our unbiased figure; 99.0% is optimistic (bugs were fixed on that month). - 51 offline tests: normalisation, every label, splits, decoys, AI guardrails (low confidence, invented IDs, bad JSON, outages). What broke: - Gemini paired same-supplier rows although the 1C row quoted a different invoice number. Fix: such rows never go to the AI (guard + regression test). - Groq gave two halves of a split invoice to other invoices. Fix: rows summing exactly to an invoice are reserved for it (98.4% → 99.0%). - Still wrong: 1C row C0155 (net mistyped 1,852.43) went to P0037 instead of P0136, same supplier, confidence 0.78. Still flagged and needs accountant confirmation, so nothing is missed. - Real month: English-named supplier with a mistyped amount; AI was not confident, so it went to review, not guessed. Limits: mostly synthetic data; one error per test case; time savings are estimates.

Worth 20 of the 100 points.

Running it

Demo: https://muhasibplus.streamlit.app (free hosting, may take 30–60 s to wake up). No login and no API key needed: it runs on a synthetic demo month and reuses saved AI answers. Path: sidebar Data = "Demo month (synthetic)", Method = "Hybrid (rules + fuzzy + AI)" → Reconciliation tab: every record with its label, evidence and confidence → "Download reconciliation report (.xlsx)" → Issue detail + AI explanation tab: open a finding → "Generate AI explanation + supplier email (Azerbaijani)" → Approve / Reject / Escalate → Evaluation (proof) tab: VLOOKUP vs rules vs hybrid on the labelled month. Switch Method in the sidebar to compare. Run locally: pip install -r requirements.txt python -m pytest -q (51 offline tests, ~5 s, no key) python evaluate.py data_realistic --out results_realistic streamlit run app.py Optional: add a free Groq key to .env (see .env.example) for new AI calls. Known limits: synthetic data except one private real month; one error per test case; free-tier AI is rate-limited; time savings are estimates.

Project ownership

The team keeps the rights to this project. Judges were given access for verification only.