Managed IT
Why PMS and EPOS integrations break, and how to catch it early
Why PMS and EPOS integrations fail: stopped interface services, expired certificates, room status and API changes, and the checks that catch silent errors.
PMS and EPOS integration usually fails at the interface between the two systems rather than inside either one: a stopped service, an expired certificate, a room status mismatch or a vendor API change. MicroNet Global, a hospitality IT specialist supporting 745+ sites across 15+ countries, monitors those interfaces rather than waiting for the night audit.
The expensive part is not the outage. Room charge posting failures are usually silent: the till prints a docket, the guest is told it has gone to their room, and nothing lands on the folio. Nobody notices until the night audit.
What is a PMS to EPOS interface?
A PMS to EPOS interface is the connection that lets a restaurant or bar till post a charge directly to a hotel guest's room account. The EPOS looks up the room and guest name in the property management system, validates that the room is occupied and the folio is open, then sends the charge with a posting code. Most interfaces run through a middleware service rather than connecting directly.
The room charge posting path, step by step
What happens when a server presses "charge to room":
1. The EPOS requests a guest lookup, usually by room number and surname.
2. The request reaches an interface service: local middleware or a cloud endpoint.
3. The interface authenticates to the PMS over TLS.
4. The PMS returns folio status: occupied, name match, folio open, credit intact.
5. The server confirms the match at the till.
6. The charge posts with a revenue centre and posting code.
7. The PMS acknowledges and the EPOS closes the transaction.
Seven steps, four systems, two vendors. A failure at step three looks identical on the till to a failure at step six, so "the interface is down" is a symptom, not a diagnosis.
Why postings fail
The causes repeat across estates.
**The interface service has stopped.** Middleware runs as a Windows service on a site server doing three other jobs. It stops after a patch reboot, or restarts and fails to bind its port. The server is up, so server-level monitoring shows green.
**A certificate has expired.** When the certificate on the PMS endpoint, the middleware or an inspection proxy expires, postings fail cleanly and instantly, usually at midnight. It is the most predictable outage in hospitality and the easiest to prevent.
**Room status mismatch.** The room is due-out, the folio closed early, the guest is on a no-post flag, or the reservation moved rooms after the EPOS cached the lookup. The interface is healthy; the transaction is legitimately refused.
**A network segmentation change.** Someone tightens a firewall rule, changes a VLAN, or moves the EPOS estate behind a new gateway as part of a [[network and Wi-Fi improvement]{.underline}](about:blank) project, and the interface port is no longer permitted. That is a change-control failure, not a technology failure.
**A vendor API version bump.** The vendor deprecates an endpoint or changes an authentication method. They announced it; the notice went to an email address belonging to someone who left in 2023.
Symptom, cause, first check
| Symptom | Likely cause | First check |
|---|---|---|
| All room postings fail, every terminal, sudden onset | Interface service stopped or certificate expired | Interface service status and certificate expiry date |
| Postings fail at one terminal only | Terminal config, local network port or stale cached credentials | Terminal's interface settings and switch port |
| Guest lookup returns no results for occupied rooms | PMS connectivity, authentication failure or a stale room list | Interface logs for authentication errors |
| Posting accepted at the till, absent from the folio | Acknowledgement not processed, or posting landed on a closed folio | PMS posting journal for the transaction ID |
| Charges land in the wrong revenue department | Posting code mapping drift after a menu change | EPOS to PMS posting code map |
| Failures began after a maintenance window | Firewall, VLAN or proxy change | Change records for the window, and firewall rule hit counts |
Payment integration is a separate problem
Room charge posting and card payment are different paths, and conflating them costs time during an incident.
Most UK and EU estates now run **semi-integrated** payment: the EPOS sends an amount to the terminal, the terminal handles card data through a P2PE channel to the acquirer, and only a token and a result come back. The till never touches cardholder data, which keeps it out of scope for large parts of [[PCI DSS compliance]{.underline}](about:blank). Fully integrated deployments, where card data passes through the EPOS, pull the whole till estate into scope.
During an incident: if cards decline but room postings work, the fault is on the acquirer path, not the PMS interface. If postings fail but cards work, leave the payment provider alone.
The other integrations that break quietly
Room charge posting gets attention because it is visible. Three others fail quietly and cost as much.
**Reservations and channel sync.** Bookings stop flowing from the channel manager into the PMS. Availability drifts, rooms get sold twice, and the first symptom is an argument at the front desk.
**Kitchen display systems.** The KDS loses its feed from the EPOS and the pass reverts to printed dockets. Service continues, so nobody raises a ticket for weeks.
**Stock and back-office feeds.** Sales data fails to export to the stock or accounting platform, gross profit reporting goes stale, and finance assumes it is a reporting lag.
What to fix, in order
**Monitor the interface, not the server.** A ping to the site server says nothing about whether the posting service is bound and answering. Monitor the service, the port, the certificate expiry date and a synthetic test posting. That gap is what a [[24/7 managed service desk]{.underline}](about:blank) exists to close.
**Own an integration map.** One document per site listing every integration: the systems, the middleware, the transport, the ports, the certificate expiry dates, the vendor contacts and the escalation path. Rebuilding that during an incident costs hours.
**Put vendors under change control.** Ask every vendor for their deprecation notice process and make sure notices reach a monitored distribution list, not an individual. Then hold your own discipline: no firewall or VLAN change touching an EPOS or PMS segment without an interface test afterwards.
**Document the manual fallback.** Every venue needs a one-page card behind the till: how to take a room charge manually, what to record and how it reaches the folio afterwards. Print it. During an outage nobody can open a shared drive.
**Test before go-live.** Test the full posting path with real room numbers, a no-post guest, a due-out room, a split bill, a void, a refund and a tip adjustment. Integration testing is the first thing compressed when an opening runs late, and it belongs on the [[critical path for a new venue opening]{.underline}](about:blank) rather than the snagging list.
Groups running several brands across territories accumulate integration debt fastest, which is why operators of [[restaurants and bars]{.underline}](about:blank) alongside hotels benefit from one partner holding the whole map. To have yours built and monitored, [[talk to MicroNet Global]{.underline}](about:blank).
Frequently asked questions
The most common causes are a stopped interface service, an expired TLS certificate on the interface path, or a folio that was closed or flagged no-post before the charge was sent. Check the interface service status first, then the PMS posting journal for the transaction ID. If the till printed a docket, the transaction exists somewhere and can be reconciled.
Written by the MicroNet Global team. If you are working through any of this for your own estate, the specialists here are happy to talk it through.