Agentic invoice automation for a Tyler Munis municipality

Context

A municipal finance department processing hundreds of invoices per week in Tyler Munis ERP had an operational bottleneck that is common in the public sector: a small team of AP clerks keying invoice headers and line items by hand because Munis does not expose a modern API path for AP posting. The client had evaluated third-party middleware vendors and found the fit poor — middleware either required a Tyler integration contract the client did not have, or promised generic OCR that did not handle the line-item structures the client's invoices used.

The client wanted an automation that (a) captured invoices from the AP mailbox, (b) extracted header and line-item data with accuracy high enough to post without review for the clean cases, and (c) wrote back to Munis directly — without a middleware fee structure and without depending on Tyler roadmap timing.

Challenge

Three constraints made this harder than a standard AP automation:

• No public Munis API for AP. Any integration had to operate the web client the same way a human accountant does.
• Line-item variability. Invoices came from hundreds of vendors with heterogeneous line-item structures, tax treatments, and unit-of-measure conventions. A single OCR template was insufficient.
• Public-sector audit posture. Every invoice decision had to be reconstructable for records request, examiner review, or FOIA response.

Approach

Thoughtwave deployed TWSS AI Invoice Automation — our production accounts-payable agent — configured for the client's Munis environment. The pipeline runs four stages:

1. Capture. The AP mailbox is monitored; emails with PDF or image attachments are pulled into the pipeline.
2. Extract. OCR plus an LLM line-item extraction step produces a structured invoice object: header (vendor, date, total, PO reference) and lines (description, quantity, unit price, tax, GL code hint).
3. Validate. The invoice is checked against the Munis PO, the vendor master, and approval rules. Clean invoices proceed; exceptions route to an approver.
4. Post. A Playwright agent runs the Munis web client, authenticates with a service account, and posts the header and line items into the AP screens with the extracted values.

Implementation followed a focused pilot:

• Weeks 1-3. Connected the AP mailbox, tuned OCR and LLM prompts to the client's typical vendor invoice formats, and scripted the Playwright interaction sequence against a Munis test environment.
• Weeks 4-6. Ran the pipeline side-by-side with the existing manual process on live invoices. Tuned validation thresholds.
• Weeks 7-8. Cut over to production posting for clean invoices; exception routing went live simultaneously.

What we built

The production system has five components:

1. Mailbox connector. Polls the AP inbox; handles PDF, image, and embedded-form attachments.
2. Extraction layer. OCR (Tesseract) plus LLM line-item parsing, with PII redaction on non-invoice content.
3. Validation engine. PO-match, three-way match, vendor check, tax sanity, approval rules.
4. Playwright Munis agent. Runs scripted interactions against the Munis web UI to post headers and line items; resilient to UI changes via selector tolerance.
5. Audit log and exception queue. Append-only log per invoice; exception queue with approver workflow and full reasoning attached.

Outcomes

• Zero manual AP data entry on clean invoices. The AP team's time has shifted from keying to exception review and vendor relationship work.
• Materially faster invoice cycle time. Invoices move from inbox to posted within minutes of arrival for clean cases; exception invoices are faster too because the AI analysis is pre-attached.
• Full per-invoice audit trail. Every posted invoice has a reconstructable chain: source email → attachment → OCR output → extracted object → validation result → approver action (if any) → Munis posting confirmation.
• No middleware fees. The solution runs on the client's infrastructure; no per-invoice or per-document fees flow to a third party.

What's next

The same platform is being extended to purchase-order capture from vendor emails using the companion TWSS AI PO Agent, and to a vendor-onboarding copilot that pre-populates vendor records in Munis from vendor-submitted documentation. Both reuse the Playwright-agent pattern and the audit layer established during the AP rollout.

For deeper context on how we approach agentic automation in regulated environments, see our AI & Generative AI service and our Digital Enterprise Applications practice.

Why the Playwright-agent pattern matters beyond Tyler Munis

The architectural pattern here is reusable across any enterprise system that lacks a modern API surface. Most finance and operations teams have at least one business-critical application that has not been prioritized for API work by the vendor. Middleware tools can sometimes bridge the gap, but they charge per-document or per-transaction, they become stale when the upstream UI changes, and they require the client to maintain a third-party integration vendor relationship. A governed Playwright-agent approach gives the client the same automation benefit with the ownership and observability controls they would apply to any internal system.

The public-sector posture matters separately. Municipal finance teams operate under records-management and audit requirements that do not tolerate black-box automation. The agent's full-trace audit log is the artifact that makes the automation acceptable to the client's legal and examiner review — not a nice-to-have, a precondition for deployment.