Show & Tell: iNVOIZY v0.9.1 #How I built an end-to-end AP & Invoice Agent with n8n, Gemini Vision, Telegram, and Math Auditing

[Sabil_Hasan]

Hi everyone!

I’m a 20-year-old student from Indonesia who recently dove headfirst into workflow automation. Over the past two months, I’ve been building iNVOIZY—an end-to-end Accounts Payable (AP) and invoice processing workflow built on top of n8n.

Coming from a background with zero corporate finance experience, I started this project to solve a very real pain point I noticed in local SMBs and agencies: manual invoice re-typing, lost attachments, and hidden math typos.

I want to share how the architecture evolved from the initial v0.9 BETA to the recent v0.9.1 BETA Math Validation update.

The Origin: iNVOIZY v0.9 BETA (The Baseline)

In the initial release (v0.9), my goal was to automate the complete lifecycle of a vendor invoice, from arrival to approval:

1. Ingestion & Archive: Detects incoming PDF/JPG vendor invoices via Gmail triggers and backs them up automatically to Google Drive.

2. AI Data Extraction: Sends the documents to Gemini 3.6 Flash (Vision) via a structured sub-workflow to extract 10 critical invoice fields without manual data entry.

3. Threshold Routing: Automatically routes invoices based on amount thresholds—sending low-value items directly to Finance Admins and high-value items to Managers.

4. Interactive Telegram Approval: Approvers receive real-time alerts via a dedicated Telegram bot, where they can approve or reject with 1-tap buttons. Built with strict Chat ID security checks and double-click prevention locks.

5. Autonomous 24h Escalation: An automated cron schedule scans pending invoices daily (>24h idle), triggering reminders and escalating unaddressed items directly to the Business Owner after two attempts.

The Blindspot I Discovered

While testing v0.9, I realized a major flaw with OCR and AI extraction alone: AI is smart, but it doesn’t do strict arithmetic.

If a vendor sends a blurry scan where a digit is misread, or if the vendor made a calculation error on their own invoice, the system would extract the wrong subtotal and pass it straight to the manager unnoticed.

Passing wrong numbers to an approver defeats the entire purpose of automation.

What’s New in v0.9.1 BETA: The Math Validation Layer

To fix this, I just shipped v0.9.1 BETA, introducing a deterministic Math Validation Layer before any invoice ever reaches an approver:

Deterministic Cross-Field Audit: A custom JavaScript node now cross-checks ⁠Subtotal + Tax⁠ against ⁠Total Amount⁠.

Tax-Scheme Awareness: Not all vendors format tax the same way. The workflow dynamically adjusts its audit logic based on whether the invoice uses an Inclusive or Exclusive tax scheme.

Flag Before Approval: If a mismatch is detected, the invoice is blocked instantly. It will never reach the approving manager.

1-Tap Telegram Correction Loop: Instead of failing silently, the Finance Admin receives a “Mismatch Alert” in Telegram with a direct link to the original document. They can reply directly in the chat with the corrected numbers, triggering an instant automatic re-validation.

Tech Stack & Architecture Summary:

Orchestration: n8n (Multi-path sub-workflows, Function/Code nodes, HTTP Requests)

Vision / AI Model: Google Gemini 3.6 Flash

Interface & Notifications: Telegram Bot API (Inline Keyboards & Callback Queries)

Database & Storage: Google Workspace (Sheets & Drive)

Video Demos & Screenshots:

Short Video Highlights: https://www.linkedin.com/in/sabil-hasan-10a5a4419?utm_source=share_via&utm_content=profile&utm_medium=member_ios

What I Learned & Looking for Feedback

Building this system entirely in n8n taught me that AI handles unstructured vision well, but deterministic code is necessary to enforce business math.

My next milestone (v1.0) is to implement 3-Way Purchase Order (PO) Matching and sync the output directly into cloud accounting software (like Xero / Jurnal).

As I am expanding my skills in workflow engineering, I would love to get feedback, critiques, or edge-case warnings from experienced n8n builders here!

Also, if any SMB or Agency in the community wants to test this setup, I’m offering a free 14-day pilot run.

Thanks for reading! Happy automating!

[Rafi_Islam]

Nice progression, especially the decision to keep vision extraction probabilistic and make the financial validation deterministic. Two edge cases may be worth testing before v1.0:

1. Normalize money to integer minor units or another decimal-safe representation before comparison. Binary floating-point and tax rounding can otherwise create false mismatches.
2. Add an idempotency key, for example vendor ID + invoice number + total + currency, before archive and approval steps so retried Gmail or Telegram events cannot create duplicate approvals.

For 3-way matching, I would also test tolerances at the line-item level, not only the invoice total, because unit rounding and partial deliveries can be legitimate. Clear write-up and a thoughtful architecture.

[Sabil_Hasan]

"Hi @Rafi_Islam,

Thank you so much for the detailed feedback and compliments on the architecture!

1. Currency Normalization: Excellent point on the binary floating-point issue. I will ensure all values are parsed into rounded integers (or minor units) before the deterministic validation node to prevent false mismatches from rounding errors.
2. Idempotency Key: Really appreciate this edge case. Combining ⁠Vendor ID + Invoice Number + Total + Currency⁠ as a unique hash key into the database prior to approval will definitely prevent duplicate triggers from Gmail/Telegram retries.
3. Line-item Tolerance: Makes total sense for partial deliveries and tax rounding gaps. I’ll make sure to bake line-item tolerance logic into the roadmap for the 3-Way Matching phase.

Thanks again for taking the time to review this!

[shipsitself]

Really like that you kept extraction probabilistic and validation deterministic — that split is the whole game. Seconding @Rafi_Islam on integer minor units; we hit exactly those false mismatches from tax rounding until we started comparing in cents.

One failure mode worth planting a test for, because math auditing alone won’t catch it: the plausible misread. We built basically the same thing (n8n + Gemini vision reading invoices) and the model once read a date of “02/08/2026” as February 8th when the invoice meant the 2nd of August — US vs EU order. The value was valid, internally consistent, and sailed through every arithmetic check, because the arithmetic was fine. It was just the wrong date.

What caught that class of error for us wasn’t a better audit of the invoice’s own numbers — it was checking the extracted fields against an external source of truth. We matched every invoice to a purchase-order list: vendor + total to the cent + a PO number that has to already exist, and anything that didn’t match went to a human. That’s what caught the things math auditing can’t see — a duplicate invoice, one with no PO at all, and a total that had quietly grown a “priority support fee.” Your idempotency key (vendor + number + total + currency) is the same instinct pointed at retries; extend it to “does this invoice correspond to something we actually agreed to buy” and you close a lot of the error/fraud surface.

Code for our version if it’s useful to compare notes: builds/ep04-invoice-agent at main · Ships-Itself/builds · GitHub

Nice work shipping this at 20 — genuinely hard domain to pick.

[Sabil_Hasan]

Hi @shipsitself,

Wow, thank you so much for this goldmine of feedback! The “plausible misread” edge case with date formats (US vs EU/ID) is such a sharp observation — arithmetic checks definitely can’t catch a perfectly calculated invoice with the wrong metadata.

Matching extracted fields against an external PO list / source of truth is a game changer for fraud detection and silent fee injections. I will definitely check out your GitHub repository to compare architectures.

Really appreciate you taking the time to share your experience and codebase!

[shipsitself]

Glad it helped! One last thing worth stealing before your v1.0, since you’re about to compare architectures anyway: run your test invoice set through the whole pipeline five times, not once, and diff the outputs. We assumed a passing run meant a passing system — then found a case that passed 3 runs out of 5. Vision models wobble on borderline inputs, and a single green run can be luck. Tracking that flip rate caught more real bugs for us than any single-run test. Good luck with the launch — the build looks genuinely solid.

[Sabil_Hasan]

Thanks a lot for the gold nugget advice, @shipsitself!

That’s a huge point on the non-deterministic nature of Vision LLMs. Testing borderline inputs with a 5x loop test to measure the “flip rate” is an brilliant approach to spot intermittent OCR wobbles before moving to v1.0.

I’ll definitely incorporate this stress-testing method into our QA pipeline alongside our database migration. Really appreciate you taking the time to share your real-world experience and inspect the build details!