Teller Government Cashiering connects to Workday through a real-time integration that pulls open invoice and customer data into the cashiering interface, then posts the completed receipt back to Workday accounts receivable as the payment is taken. A cashier searches for an account, sees live balances from Workday, applies the payment, and the receipt updates A/R without a batch upload or a nightly file. Teller is currently in production with 43 joint Workday clients.
What does the Workday integration actually do?
The integration runs in two directions during a single transaction. On the inbound side, Teller queries Workday for the data a cashier needs to take a payment: the customer or account, open invoices, amounts due, and any invoice-level detail the agency wants displayed at the counter. That means staff are looking at live Workday balances, not a copy that was synced hours ago.
On the outbound side, once the cashier applies and finalizes the payment, Teller posts the receipt back to Workday so accounts receivable reflects the payment right away. The invoice closes or draws down, and the transaction carries the reference data Finance needs to reconcile it later.
The point of the integration is that a front-counter payment updates the system of record as it happens, not after an overnight process.
This matters most at a busy counter. When A/R updates in real time, a second cashier helping the same customer, or a citizen checking a balance online moments later, sees the correct amount. It removes the window where two people can act on stale data.
How does a Workday transaction flow through Teller?
A typical counter payment against a Workday invoice moves through a handful of steps:
- The cashier searches for the customer or account inside Teller.
- Teller queries Workday and returns the open invoices and balances in real time.
- The cashier selects what the customer is paying and enters the tender (card, check, cash, or a mix).
- Teller records the receipt, prints or emails it, and applies the payment.
- Teller posts the receipt back to Workday, updating A/R against the specific invoices.
- The transaction lands in Teller's end-of-day balancing and deposit workflows for reconciliation.
Because the payment is captured in Teller, the tender detail and drawer assignment stay in the cashiering layer, where end-of-day balancing and deposit preparation live. Workday receives the clean receipt and A/R impact. The division of labor is deliberate.
Why is Teller a cashiering layer on top of Workday, not a Workday module?
Workday is a strong ERP for financials, procurement, and human capital, but it is not built to run a government front counter. A counter needs fast lookups across many departments, physical cash drawer management, check scanning and batch processing, receipt printers and other peripherals, voids and refunds handled by role, and a balancing workflow a clerk can close out at shift end. These are cashiering concerns, and they typically sit awkwardly inside a general-ledger platform.
Teller exists to be that purpose-built cashiering layer. It handles the counter, the devices, the tender, and the reconciliation, then hands Workday a well-formed receipt. The result is a clear boundary:
Responsibility | Teller (cashiering layer) | Workday (system of record)
Account and invoice lookup at the counter | Displays live data | Serves the data
Taking the payment (card, check, cash) | ✓ | —
Cash drawer and check scanning | ✓ | —
Receipt generation and printing | ✓ | —
A/R and general ledger of record | — | ✓
End-of-day balancing and deposits | ✓ | Receives posted entries
A single payment in Teller can also touch more than one system at once. It is common for a receipt to pull invoice data from one platform, post the A/R impact to another, and feed a deposit entry to a separate general ledger. Teller is in production with more than 96 third-party integrations, so Workday is one of many systems it coordinates rather than the only one it talks to.
Does connecting Teller to Workday require heavy IT work?
Teller is IT-light for the agencies who use it, and the Workday integration is built and maintained by Teller rather than assembled by the agency. Integrations are configured to the customer's Workday setup during implementation, including which invoice types appear at the counter, how receipts map back to A/R, and how deposits are represented. Your IT staff are usually involved to grant access and confirm data mappings, not to write and maintain the connector.
Teller's platform is designed for this kind of extensibility through a plugin architecture and published APIs, which is how it supports a large integration catalog on a single code base. For an agency, the practical effect is that the Workday connection is a supported product capability, not a one-off custom build that becomes fragile over time.
What should a Workday agency confirm before implementation?
If your finance team runs Workday and is evaluating Teller, a few questions tend to shape the integration scope:
- Which Workday invoice or receivable types need to be payable at the counter, and which departments they belong to.
- Whether any revenue posts to a separate general ledger rather than Workday, since Teller can feed both.
- How refunds, voids, and adjustments should reflect back to Workday A/R.
- What reference detail Finance needs on each receipt for downstream reconciliation.
- Whether other systems, such as a tax or utility billing platform, also need to participate in a single payment.
These are the details Teller works through during implementation, and they are the reason the joint Workday deployments behave consistently: the boundary between cashiering and system of record is defined up front, so the counter stays fast and Workday stays the source of truth.