Yes. Teller Government Cashiering integrates with Accela to pull permit fees at the counter and post receipts back to Accela in real time. A clerk searches for a permit, Teller retrieves the balance due, the payment is applied, and Accela is updated as paid, without staff re-keying figures into two systems.
Accela is one of many permitting and land-management platforms that Teller connects to. It is part of a production integration library that spans major government ERPs, tax systems, and utility billing. Here is how the permitting pattern works and why it matters at a busy government counter.
How does the Accela integration actually work?
The pattern is a real-time, two-way exchange between Teller and Accela. It follows the same lookup-and-post model Teller uses across its integrations:
- Lookup: A cashier searches by permit number, address, applicant, or record ID. Teller calls Accela and returns the fees due for that record.
- Present: The fees appear in Teller's cart with the correct amounts and fee codes, so the cashier is not typing dollar figures by hand.
- Tender: The resident pays by card, check, cash, or another accepted method. Teller handles the tender and receipting.
- Post back: On completion, Teller writes the payment back to Accela so the permit record reflects the paid status immediately.
Because the exchange happens during the transaction, the permit is marked paid before the resident leaves the counter. Inspectors, planners, and reviewers working in Accela see the current status without waiting for an overnight batch.
The goal is a single source of truth: the cashier works in Teller, the permit record lives in Accela, and neither team re-keys the other's numbers.
Can one transaction cover a permit and other departments at once?
Yes, and this is where a purpose-built government cashiering layer differs from a repurposed retail point of sale. A resident at the counter rarely has a need that maps to exactly one department. Teller lets a cashier assemble a single transaction that draws line items from more than one back-office system.
In practice, one payment might include:
- A building permit fee pulled from Accela
- A parcel tax balance pulled from the tax system
- A miscellaneous receipt keyed directly at the counter
The resident pays once. Teller then routes each line item back to the system it came from, applies the permit fee to Accela, the tax balance to the tax system, and records the miscellaneous item against the correct account. The general ledger and deposit entries reflect all of it. This matters because it collapses what used to be several stops at several windows into one interaction, and it keeps each department's records accurate without manual reconciliation later.
Why does the integration pattern matter for permitting specifically?
Permitting revenue is messy in ways that reward tight system-to-system integration. Fee schedules are often driven by valuation, square footage, or record type, so the amount due is calculated inside the permitting platform, not at the counter. Pulling that figure live from Accela removes a common source of error: a cashier reading a fee off a printout or estimating it by hand.
Permit records also change state frequently. A record may accrue additional fees during plan review, or a fee may be waived or adjusted before payment. Because Teller reads the balance at the moment of the transaction, the cashier collects what is actually owed at that point, not what was owed when a report was last run.
The real-time post back closes the loop on the other side. Downstream permitting steps, such as scheduling an inspection or issuing the permit, often gate on payment. When Teller updates Accela immediately, those steps can proceed without a staff member manually confirming that money changed hands.
How does Teller connect to permitting platforms technically?
Teller is a browser-based, cloud-hosted platform built on a single code base with plugin-based extensibility. Integrations are built as plugins against that shared core rather than as separate one-off products. The platform exposes a REST API and a SQL Query API, and supports .NET plugins for connecting to third-party systems.
For a permitting platform, an integration typically maps a small set of operations:
Operation | What it does
Search | Finds permit records by number, address, or applicant
Get fees | Returns the amounts and fee codes due on a record
Post payment | Writes the completed payment back to the record
Because these integrations share one code base, an agency benefits from work done for other jurisdictions rather than commissioning a bespoke connector from scratch. Teller is in production with 96+ third-party integrations, including major government ERPs such as Workday, Oracle, PeopleSoft, and SAP, alongside tax, utility billing, and permitting systems like Accela.
What does an agency need to set this up?
The heavy lifting is integration configuration, not front-counter change management. Teller is IT-light for daily operation: cashiers and clerks are the daily users, and the interface is designed so they do not need to understand the plumbing underneath. IT involvement is usually concentrated at the integration stage, where credentials, endpoints, and fee-code mappings are established between Teller and Accela.
During implementation, Teller's professional services team scopes the integration, maps the permitting fee structure to receipt and general ledger coding, and validates the two-way flow in a test environment before go-live. The same implementation covers the connections to your other systems, so the counter experience is consistent whether a cashier is taking a permit fee, a tax payment, or a parks receipt.
If your agency runs Accela for permitting and land management, Teller can sit in front of it as the cashiering and receipting layer, pulling fees, collecting payment across whatever mix of methods a resident brings, and posting the result back so your permitting record stays current.