Accounts Payable Automation Playbook (India)

Quick answer. AP automation is the discipline of moving every vendor invoice through a structured pipeline, ingestion → coding → matching → approval → payment → reconciliation, without humans touching the easy ones. The right architecture: (1) invoices arrive via email, e-invoice IRP feed, or vendor portal upload, (2) OCR + LLM extracts header and line data, (3) 2-way (PO ↔ Invoice) or 3-way (PO ↔ GRN ↔ Invoice) match runs automatically, (4) clean matches auto-approve up to a threshold, (5) exceptions route to the right resolver, (6) payment slots into the next pay run with the right TDS, GST, MSME treatment baked in. A team running this well processes 10–20× the bills per analyst as a spreadsheet-led shop.

Why AP automation is now table stakes

In 2018, a finance team handling 2,000 bills a month had 4–5 AP analysts entering invoices, hunting POs, chasing approvals over email, and reconciling at month-end. In 2026, the same volume is run by 1–2 analysts who handle exceptions while the system processes the easy 80%.

Three forces drive this:

E-invoicing has changed inputs. With ₹5 cr+ businesses required to e-invoice (since Aug 2023), most B2B invoices now arrive in machine-readable form via the IRP. The “PDF / scan / type-it-in” pipeline is shrinking.
MSME 43B(h) introduced a hard 45-day deadline for paying Micro and Small enterprises, with tax disallowance on slip. Manual AP workflows can’t reliably hit that deadline at scale.
GSTR-2B authority over ITC means every supplier invoice has to reconcile against the GST portal monthly. The tighter the AP pipeline, the cleaner the 2B reconciliation.

A modern AP function is a machine that moves bills through known states, with humans handling exceptions. The operational discipline below is what makes that machine work.

The AP pipeline in one diagram

INGEST
  ↓
  ├─ Email-to-AP mailbox  (PDF + OCR / LLM)
  ├─ Vendor portal upload (structured form)
  ├─ E-invoice / IRN feed (already-structured JSON)
  └─ EDI / API integrations (large vendors)
  ↓
EXTRACT
  ↓ (vendor, GSTIN, invoice no, date, line items, tax, totals)
  ↓
MATCH
  ↓
  ├─ Vendor master  ← match by GSTIN first, fall back to PAN, name
  ├─ PO + GRN       ← 3-way for material; 2-way for services
  └─ Duplicate check (per vendor × invoice no × date)
  ↓
CODE
  ↓ (GL code, cost centre, project, TDS section, MSME flag)
  ↓
APPROVE
  ↓
  ├─ Auto-approve (clean match, ≤ threshold)
  ├─ Single approver (above threshold, clean match)
  ├─ Multi-level approval (high-value or exception)
  └─ Manual review (variance, missing PO, hold)
  ↓
PAY
  ↓ (next pay run, with TDS, GST, MSME priority)
  ↓
RECONCILE
  ↓
  ├─ Bank confirmation back to bill
  ├─ GSTR-2B match
  └─ TDS deposit + 26Q

Every stage gets faster, cleaner, and more auditable when automated. Skip a stage and the bottleneck moves to that stage; skip two and the team is back to spreadsheet hell.

1. Ingestion, getting invoices into the system

Email-to-AP

The default channel. A dedicated mailbox (e.g., bills@yourdomain.com) receives every supplier invoice. The system:

Parses the email
Extracts attachments (PDF, image, sometimes XML)
OCR + LLM extraction on the PDF/image
LLM normalises common field variants (“Invoice Date” / “Date of Issue” / “Bill Date” all map to one field)
Saves the original attachment as the source of truth

Modern OCR + LLM hits ~95% extraction accuracy on well-formatted Indian B2B invoices, falling to ~80% on hand-filled or low-quality scans. The fallback for the 5–20% of low-confidence extractions is a quick human review of the extracted fields against the original PDF.

E-invoice / IRN feed

For vendors who e-invoice (₹5 cr+ turnover, since Aug 2023), the invoice exists as structured JSON in the IRP. With the buyer’s consent, the IRP can push:

IRN
Invoice JSON (header + line items)
Signed QR

…directly to the buyer’s AP system. No OCR needed; the data is already canonical. This is the highest-quality ingestion channel and should be the default for every e-invoiced vendor.

Vendor portal

For high-volume relationships, a vendor portal where the supplier directly uploads their invoice into a structured form removes the OCR step entirely. Particularly useful for service vendors who don’t e-invoice (under ₹5 cr or specifically exempt sectors).

EDI / API

For very large vendor relationships (e.g., FMCG distribution, large logistics), direct EDI or REST API integration makes sense. One implementation per vendor; pays off above ~1,000 invoices/year from that vendor.

2. Extraction, what to capture from every bill

Header level:

Vendor (with GSTIN where applicable)
Invoice number, date, due date
Currency, FX rate (for non-INR)
Buyer entity + GSTIN (for multi-GSTIN buyers, this disambiguates which GSTIN’s books to post into)
PO reference, if any
Place of supply
Total taxable, tax (IGST / CGST / SGST), cess, discount, total

Line level:

Item description
HSN / SAC
Quantity, unit, unit price
GST rate
Tax amount
TDS section, where applicable

The LLM-augmented OCR should also enforce arithmetic: line totals sum to header taxable; tax computes correctly per HSN; rounding is within ₹1. Fail this and the system flags for review.

3. Matching, 2-way vs 3-way

Pattern	Uses	Match against
2-way	Service invoices, no goods receipt step	Invoice ↔ PO
3-way	Material invoices for goods received	Invoice ↔ PO ↔ GRN
No match	Adhoc bills (utility, rent, professional services without PO)	Vendor master + GL code only

For 3-way:

Invoice line should map to a PO line and a GRN line for the same item
Quantity invoiced ≤ quantity received (cumulative across receipts)
Unit price within tolerance of PO unit price (typically ±2% or ₹100, whichever lower)
Total invoice value ≤ PO open value

Tolerances should be configurable per category. Commodity purchases (steel, fuel) often have wider acceptable variances; spec-purchases (custom equipment) have tighter ones.

Auto-match rate is the metric

The single most important AP metric: % of invoices that auto-match without human intervention.

Auto-match rate	What it tells you
< 60%	PO/GRN discipline is poor; vendor master messy; OCR underperforming
60–80%	Reasonable, room to improve
80–90%	Healthy mid-market
90–97%	Best-in-class; team focused on exceptions only

Below 60%, fix the upstream issues (procurement using POs consistently, GRN being posted same-day, vendor masters cleaned). Beyond 95%, the marginal effort isn’t worth it, exceptions are real and need humans.

4. Coding, GL, cost centre, TDS

For matched POs, coding is inherited from the PO (the PO already has GL + cost centre + project). For non-PO bills, coding rules:

Vendor-default GL, most vendors map to a small set of GLs. The system suggests, the user can override.
LLM-suggested coding, large language models can read the invoice description and predict the GL with 80–90% accuracy after a few hundred reference examples.
Cost centre / project, for service invoices on a project, the project tag should come from the requisition or the email signature (if the requestor’s role implies a project).
TDS section + rate, auto-derived from vendor master + the nature of the line item. Multiple-section invoices (e.g., a contractor billing for both labour and design) split into multiple lines with different TDS sections.

The team should never re-enter coding that the system can predict; their role is to confirm and override exceptions.

5. Approval workflows

A real-world approval matrix tied to spend tier and category:

Spend tier	Category	Approvers
≤ ₹10,000	Anything	Auto-approve (clean match)
≤ ₹1 lakh	Anything	Single approver: Department head
≤ ₹10 lakh	Anything	Department head + Finance Controller
≤ ₹1 cr	Anything	+ CFO
> ₹1 cr	Anything	+ CEO
Any	Capex	+ CFO regardless of amount
Any	New vendor (first invoice)	+ Procurement Head

The matrix should be driven by roles, not specific names, when someone leaves, their pending approvals route automatically to the role’s current holder.

SLAs and escalation

Each approval level has an SLA (typically 24 hours). After the SLA:

1st escalation: gentle email reminder
2nd escalation: route to the approver’s manager
3rd escalation: route to a default escalation contact (CFO office)

Without SLAs and escalation, approvals become the new bottleneck.

Mobile approvals

Senior approvers travel. Mobile approval (push notification + one-tap from the phone, with a quick view of the bill, PO, GRN, and prior payments to that vendor) is the difference between 24-hour SLAs and 5-day stalls.

6. Exception handling, the work humans should do

When a bill can’t auto-process, it lands in an exception queue. The buckets:

Exception	Resolver	Typical cause
No matching PO	AP analyst, then procurement	PO never raised, or PO closed
PO over-utilised	AP analyst, then approver	Invoice exceeds PO open amount
GRN missing	AP analyst, then warehouse	Goods received but GRN not posted
GRN-Invoice qty mismatch	AP analyst	Partial delivery, short-supplied
Price variance > tolerance	AP analyst, then procurement	Vendor invoiced higher than PO
GSTIN issue	AP analyst	Wrong GSTIN, expired, suspended
Vendor master mismatch	AP analyst	New vendor, alias, alternate name
Duplicate suspect	AP analyst	Same invoice number from same vendor
OCR low confidence	AP analyst	Poor scan, incomplete data

The exception queue should be prioritised, by aging (closer to MSME deadline), by amount, by vendor importance. Without prioritisation, the easy exceptions get cleared first while the high-stakes ones stall.

7. AP aging, the boring but critical metric

AP aging is the report that tells you what’s owed by when. The standard buckets:

Bucket	What’s in it
Current	Within payment terms
1–30 overdue	Slipped past terms in the last month
31–60 overdue	Older slips
61–90 overdue	Significant problem
> 90 overdue	Critical, vendor relationship at risk

For a healthy AP shop, the 1–30 bucket should be < 5% of total payable; > 30 should be near zero. Outside that, you have a payment-cycle problem.

For Indian companies, layer MSME aging on top, every Micro/Small (non-trader) vendor has a 45-day clock from acceptance under Section 43B(h). The AP aging report should highlight the at-risk MSME bills first.

8. Reconciliation, closing the loop

After payment, three reconciliation steps:

8a. Payment-to-bill

Bank UTR back-applied to the bills, vendor account credited, bank account debited. (See Vendor Payments Automation.)

8b. GSTR-2B

Every B2B invoice in the period should appear in next month’s GSTR-2B (assuming the vendor files on time). The reconciliation runs on the 14th when 2B drops. (See GSTR-2B Reconciliation Playbook.)

8c. TDS

TDS deducted at payment must be deposited by the 7th of the next month and reflected in 26Q for the quarter. The bill, payment, deposit, and return entries should all reference the same TDS line. (See TDS Automation Playbook.)

When all three reconcile cleanly, AP and tax compliance are aligned.

CFO dashboard, what to watch

Auto-match rate, week over week, target ≥ 85%
Average bill cycle time, receipt → payment, target ≤ 7 days
Aging buckets, distribution and trend
MSME at-risk count, bills approaching 43B(h) deadline
Exception queue depth, count, oldest exception’s age
Approval bottlenecks, pending approvals by approver, by aging
Vendor master integrity, % with full data (PAN, GSTIN, bank, Udyam)
Duplicate alerts, count, status

A weekly review of these on a 6-month trend shows the AP function’s health better than any audit.

Common operational pitfalls

Pitfall	Why it happens	Fix
Bills sent to multiple email addresses	No single intake channel	One mailbox, vendor master tells the system to expect bills here
OCR + manual re-entry	OCR confidence not surfaced	Show confidence; only review low-confidence fields
3-way match used when no GRN exists	Service invoices forced through 3-way	2-way pattern for service POs
GRN missing because warehouse forgets to post	Warehouse and AP have different cadences	Auto-create GRN on inbound delivery scan
Approval chain doesn’t escalate	No SLA enforcement	SLA + escalation built into workflow
Same invoice processed twice	Duplicate detection only on file hash	Detect on (vendor × invoice no × date)
MSME bills pile up	Aging treats all bills equally	Separate MSME aging dashboard with deadline countdown
Exception queue grows	Resolvers don’t prioritise	Sort by deadline + amount; daily standup
Bank account on file is stale	No periodic re-verification	Quarterly penny drop

The 90-day implementation plan

For an AP shop currently running on email + Excel:

Weeks	Milestone
1–2	Stand up the AP mailbox. Configure OCR + LLM extraction. Capture 2 weeks of bills as a baseline.
3–4	Vendor master cleanup. Validate GSTINs, PANs, bank accounts. Tag MSME, TDS section.
5–6	Build PO and GRN discipline upstream. Train procurement on PO requirements.
7–8	2-way / 3-way match logic configured. Tolerances calibrated per category.
9	Approval workflow live. Migrate active bills.
10	Auto-approval thresholds calibrated. Track auto-match rate weekly.
11–12	Exception queue + escalation rules tuned. MSME priority dashboard live.
13	Pay run + bank file integration with treasury (see Vendor Payments guide).

Most teams hit 60% auto-match by week 8 and 80%+ by month 4, at which point the bottleneck shifts from inside AP to upstream (procurement/warehouse).

Tooling: what to look for

Multi-channel ingestion, email + e-invoice IRP feed + portal + API
OCR + LLM extraction with confidence scoring per field
Vendor master with GSTIN, PAN, bank, Udyam, MSME tier
PO + GRN discipline integrated in the same record
2-way and 3-way matching with configurable tolerances
Approval workflow as a first-class primitive (not an email thread)
Mobile approvals for senior approvers
MSME aging as a dedicated dashboard
GSTR-2B + TDS reconciliation out of the same record
Exception queue with prioritisation
Audit trail with actor, timestamp, before/after on every state change

OneFinOps runs Payables on one record across receipt, match, approve, pay, reconcile. Compliance (GST + TDS + MSME) and audit trail are by-products. Start a free trial or book a 30-min walkthrough.

Frequently asked questions

What’s the difference between AP automation and a workflow tool?

A workflow tool (e.g., a generic approvals platform) routes documents and tracks status. AP automation is workflow + ingestion + matching + reconciliation + tax + payment, on the books. The workflow tool’s value is bounded; AP automation’s value is the integration with the books.

Should we use an OCR-only product or an LLM-augmented one?

LLM-augmented for B2B invoices in India. The variability of vendor invoice formats (small print, regional language headers, hand-written corrections, scanned-fax originals) makes pure OCR brittle. LLM normalisation handles variants the rule engine can’t.

Can we hold the OCR vendor responsible for extraction errors?

In practice, no. Most extraction-vendor SLAs cover availability, not accuracy. Treat extraction as best-effort; build human-in-the-loop confirmation for low-confidence fields.

How small a business benefits from AP automation?

Above ~200 bills/month, automation pays for itself. Below that, a disciplined spreadsheet + email workflow is fine. Above 500/month, manual is impossible.

How do we handle credit notes?

Credit notes link to the original invoice via reference. The system: (a) reduces the original payable, (b) post a credit note GL entry, (c) reflects in GSTR-1 if you’re the seller / GSTR-2B if you’re the buyer, (d) adjusts the next pay run automatically. Don’t process credit notes as separate negative bills, keep the linkage explicit.

What about petty-cash and reimbursement invoices?

Different track, usually handled in an expense management module rather than AP. The line is roughly: vendor invoices to AP, employee expense claims to expense management. Both feed the same books in the end. (See our companion expense automation post.)

How do we handle non-PO bills (utilities, rent, statutory)?

A “non-PO” workflow that routes to a default approver based on the GL coding (e.g., utilities → Facilities Head, rent → Real Estate Lead). Vendor master should mark these as “non-PO eligible” so the system doesn’t search for a PO match.

What’s the role of e-invoicing in AP?

When a vendor e-invoices, you receive structured JSON via the IRP. That’s the highest-quality input, no OCR, GSTIN-validated, totals already arithmetic-correct. Make e-invoiced vendors the default path; keep OCR as fallback for non-e-invoicing vendors.

Can AP automation reduce headcount?

Reduce the new headcount you’d otherwise have to hire as volume grows, yes. The existing team usually shifts from “data entry + chasing” to “exception handling + vendor relationship + analysis”. Most teams keep the same headcount and 3–5× the volume capacity.

Sources

CGST Act, 2017, Sections 16, 17, 31, 34, invoice rules and ITC.
Income Tax Act, 1961, Sections 40(a)(ia), 43B(h), 192–206, TDS and MSME disallowance.
GSTR-2B Reconciliation Playbook, TDS Automation Playbook, MSME 43B(h) Playbook, Vendor Payments Automation, E-Invoicing Implementation Playbook, adjacent OneFinOps guides.

This guide is operational, not legal advice. Specific tax treatment of edge cases (capex bills, non-resident bills with TDS u/s 195, RCM-eligible inward supplies) should be reviewed with your tax counsel.

Accounts Payable Automation: The End-to-End Playbook for Indian Finance Teams