What does FEL electronic invoicing mean for a Guatemala hotel in 2026?

Guatemala's tax authority, the SAT, runs electronic invoicing under the FEL regime — Factura Electrónica en Línea. For a hotel, that means every factura you issue is an electronic document (a DTE) built to SAT's schema and certified through a SAT-authorized certificador before your guest ever sees it, your hotel is the emisor on that document rather than your software vendor, and a certification that fails has to surface as a visible error rather than a silently missing invoice. Check SAT's FEL portal for the current rules and which taxpayers they apply to; what follows is the operational side that decides whether your PMS can actually live inside them.

What FEL is, mechanically

Your PMS builds an XML document describing the sale — who's issuing it, who's buying, each line item, and each tax applied. That document goes to a certificador, a company SAT has authorized to validate and stamp DTEs. The certificador returns an authorization number, and only then is the invoice a real factura. The guest receives the certified document, not the draft your system produced.

The important structural point: the DTE schema belongs to SAT, not to any individual certificador. Two different certificadores must produce identical tax from the same invoice, because they're validating against the same published schema. A vendor that has genuinely implemented FEL can therefore support more than one certificador without rebuilding its tax logic.

The taxes a hotel invoice actually carries

A hotel invoice in Guatemala is not a single-tax document, which is where a generic international PMS tends to break.

• IVA at 12% applies across billable items.
• The lodging tax at 10% — the one that appears on a DTE as TURISMO HOSPEDAJE — applies to room nights specifically, not to the restaurant charge or the laundry line on the same folio.

So a folio containing a room night, a dinner, and a minibar item carries two different tax treatments inside one invoice, and the two taxes have a required ordering on the document. A system that applies one blanket rate to the whole folio will produce a document that's arithmetically defensible and structurally wrong.

There's also a rounding trap worth knowing exists: computing each tax independently against the net and then summing can leave a total that doesn't reconcile to the gross the guest was quoted. The correct handling makes the last line absorb the remainder so net plus taxes equals the gross exactly. If your current process reconciles by hand at month-end, this is usually why.

The ISR regime setting nobody warns you about

Every DTE carries a frase declaring the emisor's ISR regime. Two are common for small hotels: the general regime, and the Régimen Opcional Simplificado with its definitive retention. These are not interchangeable — SAT rejects a DTE whose declared scenario disagrees with the emisor's actual registered regime.

The practical consequence is that "FEL support" in a PMS has to include a place to set this per property, and setting it wrong produces rejections that look like a software failure but are a configuration mismatch. Ask your accountant which regime your hotel is registered under before your first certification attempt, not after.

You are the emisor — not your software vendor

The cleanest arrangement, and the one worth insisting on, is that your hotel holds the certificador contract and the credentials. Your PMS uses those credentials to submit on your behalf; it is never the issuing party.

That matters for three reasons. Your invoices remain yours if you change software. A vendor outage doesn't become a tax-compliance problem you can't act on. And nobody between you and SAT is aggregating other hotels' invoices under a shared account.

FluxPMS is built to that model: the hotel holds its own certificador contract — Digifact and Infile are both supported — and the credentials live in that property's own settings. Certification runs asynchronously so a slow certificador never blocks a checkout at the front desk, and voiding a certified invoice is a supported operation rather than a support ticket.

What "supports FEL" should mean when a vendor says it

Four questions get you past the marketing claim:

1. Can I use my own certificador contract, or must I use yours?
2. Does the invoice separate the 10% lodging tax from IVA on a mixed folio, on the actual document?
3. Where do I set my ISR regime, and what happens when SAT rejects a DTE?
4. Can I void a certified invoice from inside the system?

A vendor that answers all four concretely has implemented FEL. One that answers "yes, we're compliant" and moves on has implemented a checkbox.

Before your first live invoice

Validate the NIT handling — a malformed buyer NIT is the most common first-day rejection. Confirm the establishment code matches what's registered for that property. Run one certification end to end and look at the returned document rather than the success message. And check what your system does with a rejected DTE: an error a front-desk clerk can see and act on is the difference between a compliance problem you fix that afternoon and one your accountant finds in three weeks.

The short version

FEL turns invoicing into a two-party operation between your hotel and SAT, with software in the middle rather than in charge. Demand that you hold the certificador contract, that mixed folios split IVA from the lodging tax correctly on the document itself, that the ISR regime is configurable, and that failures are visible. Guatemala's FEL is live in FluxPMS today as part of a country-pluggable tax layer — see how an independent Guatemala hotel runs its front desk on it, and the published pricing for what the platform costs, with no per-invoice fee attached to any of it.