Government cashiering systems integrate with an ERP in one of four ways: real-time API, scheduled file exchange, direct database connection, or middleware. Real-time API is the deepest - a payment posts to the general ledger with full GL coding within seconds, so balances stay current and the cashiering system and ERP stay aligned without nightly batch reconciliation.

‍

‍

Why does ERP integration matter for government revenue?

‍

Your ERP is the financial system of record. Every dollar a government agency collects has to land in the right fund, the right GL account, with the right coding — and do so accurately and on the same timeline as the rest of your books. Without proper integration, four problems show up at every agency:

‍

• Manual data entry. Staff re-key payment information from the point of sale into the ERP. This takes time, introduces errors, and creates reconciliation work that lands on your most experienced people.
• Delayed posting. End-of-day batch processes mean your financial picture is always a day behind reality. For agencies with concentrated payment peaks — during property tax season, for example — that lag itself is a risk.
• Reconciliation burden. When two systems track the same transactions independently, discrepancies are inevitable. Someone has to find and fix them.
• Audit complexity. Auditors trace every dollar from collection to deposit to ledger posting. Gaps between systems create gaps in the audit trail.

‍

A well-designed integration removes these four problems by giving you a single, synchronized view of revenue across both systems.

‍

‍

What are the ways a cashiering system connects to an ERP?

‍

Cashiering platforms connect to ERPs through one of four patterns. They are not equivalent — what counts as "integration" varies a lot between them.

‍

Real-time API integration

‍

This is the deepest pattern. With this setup, transactions flow between systems immediately via secure APIs.

‍

• Lookups: a cashier searches for a customer and the system queries the ERP for current balance information in that moment.
• Posting: a payment is collected and posts to the ERP within seconds, with full GL coding applied.
• Bidirectional: account adjustments, voids, and refunds sync both ways, so corrections don't get stranded.

‍

Real-time integration requires both systems to support modern APIs and typically involves initial development to establish the connection. Platforms that maintain libraries of pre-built connectors can dramatically reduce that effort.

‍

‍

File-based exchange

‍

Systems exchange data through structured files (CSV, XML, fixed-width) on a schedule.

‍

• Export: the cashiering system generates a file of transactions at end of day.
• Import: the ERP imports the file and posts the transactions in batch.
• Frequency: usually daily, sometimes more frequent.

‍

File-based integration is simpler to implement but creates lag time and adds a reconciliation step.

‍

‍

Database-level integration

‍

Systems share a database or use direct database queries to exchange information.

‍

• Read access: the cashiering system queries the ERP database for balances.
• Write access: transactions are written directly to ERP tables.
• Risk: tight coupling can create upgrade and maintenance headaches when either vendor releases changes.

‍

Database integration can be fast but introduces dependencies that need careful coordination between vendors.

‍

‍

Middleware or ESB

‍

An Enterprise Service Bus (ESB) or middleware layer sits between systems, translating and routing data.

‍

• Flexibility: a common hub can connect many systems through one piece of infrastructure.
• Complexity: middleware adds another system to maintain and troubleshoot.
• Cost: ESB platforms often come with significant licensing fees.

‍

This pattern is common in large enterprises with many systems, but can be heavier than alternative solutions for state and local governments.

‍

‍

Real-time or batch integration — which does my agency need?

‍

This is the most important practical distinction, and it has different right answers depending on your volume and how citizens interact with you.

‍

Real-time integration moves data the moment a transaction happens. A lookup hits the ERP at the moment of inquiry and a payment posts to the GL within seconds. The benefits are:

‍

• Always-current balances prevent over- or under-collection.
• Financial reporting reflects your actual position throughout the day.
• There is no reconciliation of timing differences.
• A citizen who needs to make another payment the same day sees an accurate balance.

‍

Real-time integration requires both systems to support API-based communication and a stable connection between them.

‍

‍

Batch integration lets transactions accumulate in the cashiering system, then transfers them to the ERP on a schedule. The benefits are:

‍

• Simpler to implement.
• Works with older systems that lack APIs.
• Less dependent on continuous connectivity.

‍

The trade-offs are:

‍

• Balances may be stale until the next sync.
• Reconciliation is required when timing creates discrepancies.
• Errors discovered in batch can be harder to trace back.

‍

‍

When batch is acceptable: low-volume agencies with simple workflows where a 24-hour delay does not create customer-service issues.

‍

When real-time is necessary: high-volume agencies — especially property-tax collectors and multi-location operations — and any environment where citizens may make multiple payments in a short period. When deadline volume compresses months of activity into days, stale balance data turns into front-counter problems.

‍

‍

How does Teller approach ERP integration?

‍

Teller Government Cashiering by Can/Am is built for the real-time, bidirectional pattern, with a deep library of pre-built integrations to fall back on instead of starting from scratch for every customer.

‍

• 96 production integrations across major government ERPs, utility billing, property-tax, and permitting systems. Workday alone accounts for **43 joint deployments**.
• Real-time bidirectional posting on supported systems — lookups, payment posting, GL coding, and void/adjustment sync all flow live.
• Batch options are configurable where the target system requires them, with export formats matched to the ERP's import requirements.
• Production scale: Teller's integrations run at 80+ active government clients, including Santa Clara County, CA (roughly 500,000 customers processed during tax season).
• Integration support is included in the subscription, not sold as an add-on — including compatibility testing when ERP vendors release updates.

‍

Want to know how to evaluate a vendor's integration claim — pre-built vs. custom, depth, red flags, the questions to ask? See How to Evaluate a Government Cashiering System's ERP Integration. For the full list of systems Teller connects to, see Integrations. And for a plain-language answer on your specific ERP, see How does Teller integrate with our existing ERP?.