POS System in Jordan: How to Choose One That Works with JoFotara

Eight in the evening, in a shop off a busy street in Amman. The customer pays cash, the clerk prints a receipt from the till, then opens a browser on the same machine and types the same figures a second time into the national invoicing portal so that an approved invoice comes out. Two operations for one sale, and a queue waiting.

That scene is the direct result of choosing a POS system in Jordan without asking what happens to the invoice after it prints. A till that sells quickly but does not know its way to the Income and Sales Tax Department (ISTD) leaves you with manual work every single day, and a widening gap between what you actually sold and what your books are willing to admit.

This guide is written for the owner of a shop, a restaurant or a pharmacy in Jordan, and for the accountant who has to close their month. We start with what genuinely changed at the counter once issuing through the national system became mandatory, then map the four kinds of system on offer and which one fits your size, then ten checks you can actually run before signing, each with the question to put to the vendor. The last section is the cost you will pay whether or not it appears on the quote.

What changed at the checkout counter in Jordan

Before 2025, buying a till was a purely operational decision: screen speed, training time, hardware cost. A third party has since joined it, the Income and Sales Tax Department, and the receipt you print now has a legal path behind it.

The difference is practical, not cosmetic. An invoice not issued through the national invoicing system is not accepted as a tax document, which puts the buyer’s own records at risk as much as yours: they are holding a document they cannot rely on before the department. The fine runs between 200 and 500 JOD, doubles on repeat, and carries possible exclusion from government tenders.

The mandate has been in force since 1 April 2025, with enforcement tightening since. It covers sellers of goods and services generally, professionals included, not only businesses registered for sales tax. A non-registered seller issues an income invoice, a registered one a general sales tax invoice. The approved invoice is the one carrying the department’s QR code.

• The thresholds: exemptions tied to specific activities at 75,000, 30,000 and 150,000 JOD depending on the activity, plus a special rule for lawyers, where a receipt voucher is accepted instead of an invoice for anyone whose collected revenue does not exceed 50,000 JOD a year, and whoever passes that mark issues an invoice within 45 days of reaching it.
• The list is not closed: activities have been added to it since it was issued, so do not work from an old copy.
• The exemption follows the activity, not the size: the condition is that you genuinely practise the activity, not that you are a small business.
• And it is not permanent: the Director may impose the obligation where there is evidence the threshold has been passed.

Check the text currently in force at the department before you build a decision on it.

The short version of this section: the checkout screen is no longer the end of a sale. It is the beginning of one.

Where the POS sits in the national invoicing system, exactly

The most common misunderstanding among buyers is the idea that the till itself is what “connects to the department”. In practice the sender is the accounting system standing behind the point of sale, and the real path has three steps rather than two.

Step one: registration and credentials

You log into the department’s e-services, go to the invoicing system, and choose Device Linking from the main screen. You generate a Client ID and a Secret Key there, and complete the technical requirements for the link. Those two credentials are your responsibility alone, and any unauthorised use of them falls on you. That is the path for a business that has accounting software; a business without one adds a sub-user and issues its invoices manually from the portal.

Step two: building the invoice and sending it

The invoice is built as UBL 2.1 XML, encoded in Base64, and posted to the department’s API together with the two credentials. No digital signature and no encryption certificate is required from your side. It is not a Jordanian requirement, so do not let a vendor sell you a “digital signature” as one.

Step three: clearance and the code

The department returns the invoice status, and on approval the QR code comes back with it. The code originates at the department; your system only prints it on the receipt. Any vendor telling you their software “generates the QR code” is describing something other than what actually happens.

Which is why the right question at purchase is not “is the till connected to the department?” but “who in my setup is responsible for sending, and does the sale reach them without being keyed in again?”. If you want the full cycle before you go on, we have walked through how the national e-invoicing system works step by step.

Four kinds of POS system in the Jordanian market

The market is not one row of products. It is four categories that differ in architecture, in cost and in the compliance path they leave you with. Working out which category you are shopping in cuts half the comparison work before it starts.

Category one: a closed till unit

A box that prints a receipt and totals the day’s sales, with no API and no structured export. It is the cheapest option, but it has no route to the national system, so invoicing stays a manual job in the portal. It suits someone selling a handful of items and issuing very few invoices a month, and nobody else.

Category two: local POS software on a machine in the shop

It handles items, stock and shifts well, and its data lives on one machine. The catch is that connecting to the department depends on whether an open API exists, and that backups and any second branch remain your responsibility rather than the vendor’s.

Category three: standalone cloud POS software

Quick to switch on, works from any branch, and updates itself. It usually stops at the sales boundary though: no general ledger, no supplier payables, no financial statements. So you need an accounting system after it, and the double-entry question walks back in through the side door.

Category four: a point of sale inside a full accounting system

Here the sales screen is the front end of a single system. The sale draws down stock, books the revenue, produces the invoice, sends it to the department and lands in the financial statements without an intermediate step. This category usually costs more per month and far less in manual work.

There is no category that is best in the abstract. The practical rule is that the more daily invoices, items and branches you have, the further up this ladder you move. For a wider comparison at the level of invoicing software rather than tills alone, read our guide to the e-invoicing requirements in Jordan.

Ten checks before you buy a POS system in Jordan

Every check below can be run before you sign, and each comes with the question to put to the vendor word for word. Ask for a written answer, not a slide.

Compliance: who sends the invoice, and how

1. The invoice path from screen to department. Ask: “Show me one sale on the checkout screen, and show me that same invoice approved with its code printed, without anyone touching a keyboard twice.” If the demo needs copy and paste, what you are buying is double entry.

2. Behaviour when the connection drops. Clearance in the national invoicing system is real time: an invoice does not become an approved tax document until the department returns the QR code, and no offline mode that substitutes for that appears anywhere in the official guides. Ask: “What happens to the sale if the connection drops, how do I see which invoices have not been cleared yet, and when are they sent?” What you are looking for is transparency, meaning a clear list of what is still uncleared and a resend that uses the original identifiers the moment the line is back, not a promise that an outage “makes no difference”.

3. Resend behaviour. An invoice is identified by its number and its UUID together. When a send fails, the retry must carry the same pair. Generating a fresh UUID does not get the invoice rejected, it gets it accepted a second time, and a duplicate is booked at the department. Ask: “Does your system resend with the original number and UUID?” It is a technical question, and it exposes an unserious vendor immediately.

Invoice accuracy: returns, classification and tax

4. Returns and corrections. An issued invoice cannot be edited. Correction happens through a return invoice, which is a credit note, on quantities only, and never above the original quantity. Ask: “How does the till handle returning one item out of an invoice with five, and does it tie the return to the original sale line?” Return lines are matched to the original line item ID, so keeping that ID is a practical condition for partial returns to work at all.

5. Correct invoice classification. The system knows two invoice values, new and return. Above that sits a three-digit code combining trade type, payment method and tax family. Any simplification along the lines of “cash always means one code” is wrong. Ask: “How does your system pick the code for a local cash sale versus a sale on account?”

6. Tax calculated at line level. The base general sales tax rate is 16%, and alongside it sit reduced rates, exempt items, zero-rated items and a special sales tax on certain goods. Ask: “Can I fix a different rate per item, and does the tax subtotal come out correctly on the invoice?” Systems that force one rate across the whole shop will break your return. For the detail, see our guide to general sales tax in Jordan.

Daily operations and control

7. Stock moving with the sale, in the moment. A point of sale that does not draw down stock leaves you a manual count every month. What you want is a balance that reflects each sale as it happens, not a figure you discover at month end. Ask: “Does the item balance show as updated straight after the sale, in the same report the accountant looks at?”

8. Shift close and cash control. Ask: “Show me a shift-close report with expected, actual and variance, split between cash and card.” That report is your daily cash-count tool, and its absence means till differences surface late and with no traceable source.

9. Permissions and an audit trail. Who can void a sale? Who can grant a discount? Who can open the drawer? Ask: “Show me a log of who cancelled an invoice and when.” The department expects a full trail of sends, responses and resends, and internal permissions are the second half of that protection.

After you sign

10. Getting your data out. Ask: “If I end the subscription, in what format do I extract items, customers and the sales history?” A vendor who cannot answer that plainly is selling you a door that locks behind you.

At this point a quick diagnostic is worth more than more reading: the JoFotara readiness check gives you a picture of the gaps in your current setup in a few minutes.

What not to base your decision on

Do not base it on an “officially approved” claim. The department publishes no list of approved solution providers and no accreditation programme. The claim a vendor is entitled to make is integration with the national system, not approval by it.

Do not base it on a “government test environment”. The official guides describe no sandbox. A vendor may offer a trial environment of their own, which is a different thing.

Do not base it on how the screen looks. A pretty interface is tested in ten minutes; the accounting path takes a full monthly cycle. Ask for a trial account and run five real situations from your shop.

Do not base it on the headline price. The real cost items come further down, and they usually dwarf the subscription gap between two options.

Do not base it on a feature promised in the next release. Compare systems on what you can watch working today. A feature that has not shipped is not part of the deal.

Why POS invoices actually get rejected

• A missing or wrong buyer tax number where it is mandatory, such as selling inside the development areas. A data-completeness failure, not a technical fault.
• Totals that do not reconcile between the line sum, the tax total and the final total, which the department returns as a total is not correct message. Rounding in two places is one way it happens; the tolerance is 0.001.
• A duplicate invoice from resending with a newly generated UUID after an outage. The second submission is not rejected. It is accepted and booked as a second invoice, which is worse than a rejection because nothing warns you of it. Resending the original number and UUID returns an already-submitted status with the original QR code, the sanctioned way to recover a code you failed to store.
• An invoice counter never set up. A whole number starting at 1, incrementing on every invoice.
• A discount at invoice level instead of distributed across the lines.
• Editing an issued invoice instead of a return invoice.

One error message is worth separating out, because it looks like the duplicate case and is not: the complaint that an ID must be unique refers to the line item IDs inside a single invoice, which is a different identifier from the invoice number and UUID.

The operating rule: take the invoice’s final state from the invoice status field the department returns, never from the fact that the call succeeded. And keep the number, the UUID, the code and the status for every invoice, because those four fields are what save you in any review.

To check an invoice you have been handed, the only recognised route is verification through the Sanad app under the digital document verification option. No general QR reader does this job.

Five everyday situations that expose any system in an hour

Do not judge a system from the presentation. Ask for a trial account and run these situations yourself. Each of them happens in your shop weekly, and each exposes a different weakness. Set aside one hour and sit at the screen yourself rather than letting the salesperson drive. Bring real data: five of your own items with their prices and tax rates, and a corporate customer name with a tax number. Invented cases pass on every system; real ones expose the weak ones. After each situation, record three things: whether it finished without a second entry, how many steps it took, and what the employee saw when they made a mistake. Those three notes make a usable comparison table between two quotes, where a general impression does not. And if a vendor refuses to let you try it yourself, that is already an answer.

1. Case one, a customer who wants an invoice in their company’s name after paying. Try issuing an invoice carrying the buyer’s tax number after the sale has closed. A good system lets you set the buyer type before clearance and classifies the invoice accordingly. A weak one prints a receipt with no buyer data and then leaves you to issue a second invoice by hand.
2. Case two, returning one item three days later. Open the original invoice and return a single item from it. Watch two things: did the system tie the return to the original sale line, and did the item go back into stock? If it asks you to enter the return as a fresh standalone invoice, you are looking at monthly manual work in reconciliations.
3. Case three, a discount on one item inside an invoice with five. The discount has to appear at line level and the tax has to be calculated on the value after the discount. The national system does not accept a discount at invoice level; it must be distributed across the lines before sending.
4. Case four, a sale during a connection outage. Disconnect the internet, complete a sale, then reconnect and watch. The invoice does not become an approved tax document in the meantime, because clearance happens at the department at the moment of sending, so what you are testing here is how the system behaves in the gap. Was the invoice sent automatically once the line came back, and with the original number and UUID? Can you see a list of the invoices that have not been cleared yet, with the status of each? Transparency matters more than speed here.
5. Case five, closing a shift with a cash variance. Enter an actual amount five dinars below the expected figure and ask for the report. The variance should appear logged against the employee and the time, not swallowed into the daily total.

Run the five on hardware resembling what you will actually use in the shop, and at the internet speed you have rather than the one they have. If a system clears them in front of you, you have tested the parts you will genuinely rely on every day. And whatever you did not test yourself, do not assume is there.

Migrating from an existing POS

Most businesses are not buying from scratch. They are moving off something they have run for years, and the move is a data transfer, not an installation.

First, clean the item list before the move, not after. Duplicates and three names for one product multiply their problems in the new system, and you are reviewing the whole list anyway.

Second, fix the opening balances at a single date. Enter stock, cash and customer receivables exactly as they stood on one chosen day. Mixing two dates causes most of the differences that surface later with no traceable origin.

Third, run both systems in parallel for one week. A week exposes the differences; longer exhausts the team. Then compare three numbers only: total sales, total tax, and the balance of five fast-moving items.

Fourth, train on the exceptions, not on ordinary selling. An employee learns ordinary selling in an hour. What needs training is returns, discounts, voids and shift close, the operations that generate accounting errors.

The numbers your POS should give you every day

A good point of sale is not a printing machine. It is a data source. If these numbers are not available daily at one click, you are running your shop on instinct.

Cash variance per shift. Expected against actual, split between cash and card. A recurring variance on one employee is not a coincidence, and a recurring variance across everyone means the procedure is broken rather than the people.

Average invoice value. A single number that measures the effect of your offers, your shelf layout and your upselling behaviour.

Slow-moving and fastest-turning items. These two reports release the capital stuck on your shelves.

Margin at item level rather than shop level. This is where it pays to tie indirect costs to the activities that actually consume them, instead of spreading them at one flat rate across every item.

Monthly performance ratios. Once point of sale data reaches the books automatically, ratio analysis becomes an ordinary monthly routine instead of a manual project.

The real cost before you sign

• Hardware: screen, printer, barcode scanner and cash drawer, and their useful life. Budget one spare part, because a dead printer stops the selling, not just the invoicing.
• Setup and item entry: building the item tree, prices and tax rates correctly, once. Ask who does it and who pays for it.
• Connecting to the national system: inside the subscription or a separate line? Ask outright, and ask who absorbs the cost of a change forced by a later update to the department’s requirements.
• Training and staff turnover: every new hire is a repeated training cost, and a simple system saves it. Work it out at last year’s actual turnover rate.
• Extra users and branches: many quotes are priced per user, so count your team as it will be in a year.
• The manual work that remains: if somebody re-enters invoices for an hour a day, that is more than 250 working hours a year. Price it at what that hour costs and set it beside the subscription gap.

The monthly subscription is a seventh item on top of those six, so add them all up over a year before comparing two quotes. The last item is normally the one that flips the comparison. The system with the cheaper subscription is very often the more expensive one to run, and the difference shows up in the payroll rather than on the vendor’s monthly invoice.

And before you settle the free portal versus paid system question, read the detailed analysis of exactly that trade-off in our piece on the national invoicing portal and when it stops being enough.

Two special cases: the restaurant and the online store

A restaurant is not an ordinary shop. A shop sells a basket and it ends there; a restaurant sells an open order that changes between seating and payment, with the kitchen, the floor and delivery all taking part. So you need an order screen, table management and ingredient-level stock deduction. Costing runs at the ingredient level, not the dish level, and a till that does not deduct ingredients leaves you a manual count every week.

An online store is a second sales channel, not a second system. Selling in the shop and online at once risks two stock records and two sets of books. The right path is for both channels to feed the same system, so a sale draws down one balance whichever side it came from. Ask who issues the invoice when the order arrives from the web rather than the screen.

We have covered connecting an online store separately, and our guide to who must use e-invoicing in Jordan covers the scope question.

How Qoyod helps

Qoyod is a full accounting system, and invoicing sits inside the cycle, not in a separate app. In practice:

Invoicing and compliance on one path. Qoyod’s accounting software is compliant with the national invoicing system, so the invoice is issued, reaches the department and the returned code is printed, while the sale is booked in the ledger in the same operation.

A clear route if you already have a till. What matters is that it feeds one system that owns the sending. The JoFotara integration page covers that, and there is a walkthrough of how to connect to JoFotara.

For restaurants specifically. Q.Flavours is Qoyod’s restaurant point of sale product: orders, kitchen screen, tables, menus and ingredient tracking, syncing directly with Qoyod accounting. The compliance path stays with the accounting software.

Operating experience under a comparable mandate. More than 25,000 businesses run on Qoyod under a comparable e-invoicing mandate in the Saudi market. That is operating experience under a mandate, carried across to Jordanian rules.

• Support runs through live chat, email and WhatsApp.
• Where to look next: Qoyod in Jordan sets out the local picture.

Frequently asked questions

Does the till itself have to be linked to the Income and Sales Tax Department?

No. The link sits at the level of the system that builds the invoice and sends it using the two credentials you obtain from the device linking service. The till may be a sales interface only, provided the sale moves from it into that system automatically.

Can I edit an invoice the till issued by mistake?

An issued invoice cannot be edited. The correction is made by issuing a return invoice, which is a credit note, on quantities only, and never exceeding the original quantity on the first invoice.

What do I do if the internet drops during peak hour?

Clearance is real time and happens at the department, so the invoice does not become an approved tax document before the QR code comes back, and the official guides describe no offline mode that changes this. Ask the vendor how the system lists the invoices that have not been cleared yet and how it resends them with the original number and UUID once the connection returns, and ask to see that scenario demonstrated before you buy.

Is there an official list of approved POS systems in Jordan?

There is no published list of approved solution providers and no published accreditation programme. What you can verify is whether a system integrates with the national system in practice, and the best test is watching a real approved invoice issued in front of you during the demo.

How do I check that an invoice I received from a supplier is genuine?

Scan the QR code with the Sanad app under the digital document verification option. The app tells you whether the document is valid and shows the basic invoice data carried inside the code. No other QR reader performs this task.

Do I need particular hardware or a specific brand?

Sending happens from the software through the department’s API rather than from the device, and the technical guides do not address particular hardware. What matters in practice is that the printer and the barcode scanner work with the software you chose, and that the printer can print the QR code clearly enough to be scanned.

How long does connecting a point of sale to the national invoicing system take?

Obtaining the Client ID and Secret Key happens at the department through the device linking service. The longer part is normally configuring items, tax rates and opening balances in the system, and that depends on the size of your item list rather than on the technology.

My shop is small and I issue few invoices, do I need POS software at all?

Not necessarily. If your daily invoice count is limited and your item list is short, issuing invoices straight from the accounting system may be enough. The practical rule is to move to a point of sale when the queue or the number of items is what slows you down, not when a vendor tells you to.

The bottom line

Choosing a POS system in Jordan today is a decision about a path, not about a device. A screen that sells quickly and then leaves the invoice suspended between you and the portal shifts the cost off the vendor’s invoice and onto your employees’ hours, and it surfaces late, as till differences and returns that do not reconcile.

Test any system with three questions only. Does the sale reach the department and your books from a single entry? What happens when the connection drops? And how does it handle a partial return? Systems that clear those three deserve a detailed comparison; the rest save you time by being ruled out early.

Start with one step this week. Count how many invoices get keyed in twice in your shop each day, and multiply that number by two minutes. The result is the cost you are already paying without it appearing on any subscription invoice, and it is the number to hold every quote up against.