Connecting your POS to your accountant without monthly re-keying

At the end of every month, a familiar exchange: the accountant asks for the sales figures, someone exports a spreadsheet, and a few days later come the questions about why the VAT does not tie out.

A proper integration removes that entirely. Here is what it involves.

What actually needs to flow

You do not need every transaction in your accounting software. You need a correct daily summary:

The daily sales journal:

• Revenue, split by the categories your chart of accounts uses
• Output VAT, split by rate
• Payment methods: cash, mada, credit card, transfer, BNPL
• Refunds and credit notes
• Discounts as their own line
• Rounding

Purchases, if your POS raises them: supplier, amount, input VAT, and the goods receipt it relates to.

Cash movements: drops to the bank, petty cash out.

That is the whole picture. Individual transaction lines stay in the POS, where they belong, and the accountant gets a journal per day.

The four agreements to make first

Before switching any integration on, sit with your accountant for thirty minutes and agree:

1. The chart of accounts mapping. Which POS category maps to which account. Get this wrong and you will be unpicking journals for months.

2. VAT treatment per product category. Confirmed once, and then it is correct on every future transaction. SeeVAT basics.

3. How payment methods map. Cash to the till account, card to a clearing account that is reconciled against settlements, not directly to the bank — because the settlement arrives later and net of fees.

4. Daily or monthly. Daily journals are more work to review but make reconciliation trivial. Monthly is one entry and harder to unpick when something is wrong. Most accountants prefer daily.

That clearing-account point in item 3 is the one that causes the most confusion. Card sales do not arrive in your bank on the day they happen, and they arrive net of processing fees. Posting card sales straight to the bank account guarantees a reconciliation difference every single day.

The three integration levels

Level 1 — manual export. A CSV the accountant imports. Works, and it is a monthly task somebody has to remember.

Level 2 — scheduled export. The system emails or uploads the journal daily. No one has to remember.

Level 3 — direct integration. The POS posts journals into the accounting software through its API. Least effort, and it requires the mapping to be right, because errors arrive automatically too.

Wameed exports toQoyod, QuickBooks and Xero. To be explicit about what we do not do: there is no native general ledger and no payroll inside Wameed — accounting is an export, not a replacement. See thecomparison page for how that sits against systems that do include a ledger.

What still needs a human

Integration does not remove the accountant, and should not:

• Fixed assets and depreciation
• Payroll and end-of-service
• Rent, utilities and expenses not passing through the POS
• The VAT return itself
• Year-end adjustments

The integration handles the high-volume, repetitive part — which is exactly the part that is expensive to do by hand and error-prone when done monthly from memory.

How to verify it is working

In the first month, check three things weekly:

1. Does the day's revenue in accounting match the POS shift reports? To the halala.
2. Does output VAT match what the POS reports for the same period?
3. Does the card clearing account clear when settlements arrive?

If all three hold for a month, you can stop checking weekly and check monthly.

The ZATCA connection

Your e-invoicing obligation is separate from your accounting software. The POS reports invoices to ZATCA; the accounting software receives journals. Both must agree, and the place they most often disagree is VAT rounding — seerejected invoices.

Agree the rounding treatment once, at setup, with your accountant.

See theintegrations page for the current list.