n8n Invoice Extraction: Vendor PDF to Claude to Tally in 12 Nodes

Our finance team used to spend Wednesday afternoons keying vendor invoices into Tally. 60–90 PDFs a month, average 8 minutes each. That is 9 hours of senior accountant time disappearing into copy-paste, with a 4–5% transcription error rate. We replaced it with an n8n workflow: Gmail label triggers, Claude vision extracts the line items, n8n normalises GST splits, and the output is a Tally-importable XML file. 12 nodes, ₹4.20 per invoice, zero transcription errors in 240 invoices since deploy. ## TL;DR A Gmail label trigger fires when a vendor invoice email lands tagged auto-invoice. The workflow downloads the PDF attachment, ships the base64-encoded pages to Claude Sonnet 4.5 with a strict-schema vision prompt, parses the JSON, normalises the GST splits (CGST/SGST for intra-state, IGST for inter-state based on supplier GSTIN's first 2 digits), then emits a Tally XML voucher file uploaded to Google Drive and pinged to the accounts team for one-click import. ## Why this matters now — April 2026 Two changes in 2025-26 made this finally clean. Claude Sonnet 4.5 (released Sep 2025) handles multi-page PDF vision in a single API call — older models needed page-by-page processing with stitching logic. And TallyPrime 6.1 (Feb 2026) shipped an updated XML import schema with cleaner GST tagging — the same XML that used to fail with "unknown GST head" now imports clean. A [Reddit thread on r/Indian_Accounting from March 2026](https://www.reddit.com/r/IndianAccounting/) — "anyone automating Tally entries from PDF?" — has 80+ comments on this exact pain. Most CAs are still doing it manually because the available tools (Tally Connector, ClearTax SmartImport) cost ₹25k–₹50k per seat. The n8n approach is one-time setup, ₹0/month seat cost, and runs on infra you already pay for. ## The workflow at a glance ## Prerequisites

• n8n v1.121+ with Gmail OAuth2 credential configured
• A Gmail account where vendor invoices land. Create a Gmail label called auto-invoice and a filter that auto-applies it to mails from your known vendors
• Anthropic API key with Claude Sonnet 4.5 access (Haiku is not accurate enough for line-item extraction)
• Google Drive access from the same Google credential, with a folder for generated Tally XMLs
• TallyPrime 6.1+ on a Windows machine, ODBC or import-folder configured
• A clean list of your existing Tally ledger names (used in the prompt to map vendor names to ledgers)

## Step 1 — Gmail label trigger n8n's native Gmail Trigger node polls every 5 minutes by default. Configure it to watch only the auto-invoice label and to include attachments. The trigger emits one item per email plus binary fields for each attachment (attachment_0, attachment_1, etc.). A Filter node downstream keeps only items with PDF binary, dropping spurious images/signatures. After processing, the workflow marks the email read and adds a processed-invoice label (Gmail node, modifyLabels operation) so the trigger never reprocesses the same mail. ## Step 2 — Claude Sonnet 4.5 vision extraction This is the core node. We send the PDF bytes (base64) along with a strict-schema prompt. The 2026-vintage Anthropic API accepts PDF directly as a document content block — no page-splitting needed. The HTTP Request node body: Why Sonnet 4.5 and not Haiku 4.5? Haiku misreads HSN codes about 8% of the time and confuses CGST/SGST splits on dense tables. Sonnet 4.5 at ₹2.50/invoice is worth the upgrade for accounting accuracy — we tested both on 50 invoices side-by-side. Haiku had 4 errors, Sonnet had 0. Real cost math: average invoice = 1.4 PDF pages, ~6,000 input tokens (image+text), ~600 output tokens. Sonnet 4.5 at $3 / $15 per million = (6000 × $3 + 600 × $15) / 1M = $0.027 ≈ ₹2.25. Round to ₹2.50 with overhead. ## Step 3 — GST normalisation code node The trickiest accounting logic: deciding whether to record this as CGST+SGST (intra-state) or IGST (inter-state). The rule: - If supplier's GSTIN state code (first 2 digits) === buyer's state code → intra-state, split into CGST and SGST. - Otherwise → inter-state, single IGST line. Our company is in Maharashtra (state code 27). The Code node: The requires_review flag is the gate before we generate XML. If true, the workflow routes to Slack instead of Drive, and the finance team eyeballs the invoice. About 5% of invoices flag — usually because of round-off issues on the vendor side, not our extractor. ## Step 4 — Tally XML emission TallyPrime 6.1 imports vouchers via XML in a specific envelope. The minimum schema for a purchase voucher: Things to know about this XML: - ISDEEMEDPOSITIVE controls debit/credit. The party ledger is credit (No → it is a credit entry), the expense and tax ledgers are debits (Yes). Amounts are positive on credit side, negative on debit side. This is Tally's convention, not standard double-entry vocabulary. - ALLLEDGERENTRIES.LIST must balance: sum of all amounts = 0. Our Code node validates this before emitting. - PARTYLEDGERNAME must exist in your Tally company already. If a vendor is new, the import fails. Hence the vendor-mapping section in the Claude prompt: we want Claude to use ledger names that exist, not invent new ones. - For intra-state, use two tax entries: Input CGST @ 9% and Input SGST @ 9%. Tally will figure out the GST math if your ledgers are tagged with the right tax classification at master level. A Function node generates this XML by interpolating values: The Google Drive node uploads the binary to a /Tally Imports/2026-04/ folder, and a Slack node drops a link into #accounts-imports: "{{ vendor_name }} invoice {{ invoice_number }} for ₹{{ total_amount }} ready to import. [Open]({{ drive_url }})". ## Cost comparison For 80 invoices/month: ## When NOT to do this Handwritten invoices. Claude Sonnet 4.5 vision is excellent on printed PDFs, but handwritten kirana-shop invoices are 60% accuracy max. For those, use a dedicated OCR service (Microsoft Form Recognizer, ~₹3/page) before Claude. Invoices with critical regulatory data your team must verify. Some industries (pharma, defence) require human sign-off on every entry. The workflow still saves them time on data entry but you cannot auto-import — change the destination from Drive-folder to a Slack approval flow. You do not use Tally. If you are on Zoho Books, Marg, or BUSY, the XML schema differs. Zoho Books takes the JSON directly via their API (cleaner integration, skip the XML entirely). The first three blocks of this workflow stay the same; only step 4 changes. ## Mini case — Hyderabad export firm, ₹12 Cr revenue The client: a 35-person spice exporter in Hyderabad. They processed about 140 vendor invoices/month — packaging, freight, agri-input chemicals, lab tests. Their CA charged ₹35,000/month for bookkeeping, half of which was data entry. After 4 months on the workflow: - 134/140 invoices auto-import without review (96%). The 6 reviewed are usually freight invoices with non-standard formats. - Data-entry time per invoice down from 8 min to 12 sec of review. - Their CA's fee dropped to ₹22,000/month (he kept compliance review, lost the keystroke labour). - Annualised saving: ₹1.56 lakh + ~75 hours of internal time. The architecture is the same vision-based pipeline pattern we use across [AI automation projects](https://softechinfra.com/services/ai-automation), originally proven on document workflows for [PenLeap](https://penleap.com), our in-house edtech product where the same Claude vision API extracts handwritten student answers for rubric-based scoring. Different problem, identical building blocks. ## Common mistakes Mistake 1 — Skipping the GSTIN check. Without normalising state code vs your state, you will book inter-state purchases as intra-state in 20% of cases. ITR mismatches surface in GSTR-2B reconciliation 6 weeks later. Always run the state-code logic. Mistake 2 — Using Haiku for line-item extraction. It is tempting because it is 10× cheaper. Resist. Sonnet 4.5's accuracy on HSN codes and tax breakdowns is materially better for accounting. Mistake 3 — Auto-creating ledgers in Tally. Do not. Force the workflow to fail loudly if a vendor name does not match an existing ledger. Auto-creation leads to ledger sprawl ("AWS India", "Amazon AWS", "AWS India Pvt Ltd" — three ledgers, same vendor). Mistake 4 — Storing PDFs forever in n8n. Invoices are sensitive. Push the original PDF to Drive with the right access policy, then delete the n8n binary after processing. Set EXECUTIONS_DATA_PRUNE=true and EXECUTIONS_DATA_MAX_AGE=168. Mistake 5 — Not validating amount-in-words. Claude reads "Rupees Seventy-Five Thousand Only" and the numeric reads ₹7,50,000. Always validate against the numeric. About 1% of vendor invoices have this mismatch — usually a typo on the vendor's side, but catching it saves you arguing about it in March. ## FAQ ### How accurate is Claude Sonnet 4.5 on Indian GST invoices? Across 240 invoices in 4 months we have 0 line-item errors that made it to Tally. Pre-review, Sonnet flags about 5% as needing human eyes — mostly because of split tax codes, photocopied scans, or vendors who innovate on layout. The 95% direct-pass rate is the bar we measure against. ### What if the vendor sends an image instead of a PDF? The workflow has a branch: if the attachment is JPG/PNG, it runs through the same Claude vision call but as an image content block. Accuracy on a clean photo is similar to PDF; a skewed phone photo drops to ~80%. ### Can it handle multi-currency invoices? Yes. Add currency and exchange_rate to the schema. Claude reads the currency symbol; n8n looks up the daily INR rate from xe.com or an FX API. Tally records in INR with a foreign-currency note in the narration. ### How do I handle reverse-charge GST? Mark the vendor ledger with Reverse Charge classification in Tally master. The XML import respects it; you do not need to change the workflow. But the Claude prompt should detect the "Reverse Charge Applicable" note common on unregistered vendor invoices, and flag it in the narration. ### What is the recovery if the Tally import fails? The XML upload to Drive does not auto-import — your accountant clicks Import in Tally. If Tally rejects (usually a ledger-name mismatch), the file stays in Drive untouched. The Slack message includes the error pattern to look for. We have had 3 failures in 240 invoices, all ledger-name typos in the Claude output. ### Can I trigger from a folder watch instead of Gmail? Yes. Replace the Gmail trigger with a Google Drive Trigger (watching the "Inbox" folder). The rest of the workflow is identical. We use this for clients whose vendors send invoices to a shared Drive folder instead of email. ### Does Anthropic store our invoices? Per Anthropic's data-use policy as of April 2026, API calls are not used to train models and are retained for 30 days for abuse monitoring only (Tier 2 paid accounts can request zero retention). If your CFO needs zero retention, request it via your Anthropic account manager.