The Numbers You File Under
A payroll engine that computes statutory deductions correctly is only half of a filing. The other half is the reference numbers those deductions are filed under — and an earlier version of this page got our own answer to that wrong.
A payroll system has two jobs and they are less related than they look. One is arithmetic: work out what is owed. The other is identity: know who it is owed for, in the terms the receiving authority uses.
The first is the hard-looking one and it is the one every payroll product does. The second is trivial-looking and it is where filings actually fail.
What we found in our own schema, and what we got wrong
This page first said that two scheme-number columns on our employee table were read by nothing, and concluded that the product could not hold the numbers a filing is made under. The first half was true. The conclusion was not: those columns are legacy, and the identifiers had already moved to a store of their own that the audit did not look at.
That store holds statutory identifiers per country, each with its local label — a tax PIN, a social-security number, a health-scheme number and, where a market needs it, a disability exemption certificate. They are entered on the employee form, encrypted at rest, shown masked to the last four characters and revealed only through an audited action. The employer’s own tax PIN and social-security number sit in HR settings.
A deduction calculated to the cent is only fileable if the system can also say whose account it belongs in.
Why this is the expensive kind of small
Because of what it does to the export. A payroll export that carries every figure and no scheme numbers is not a file somebody submits. It is a file somebody has to enrich, employee by employee, from a spreadsheet they maintain separately.
That enrichment step is where the errors live. A number transposed, an employee missed, a leaver still on the list, a new joiner whose number nobody has yet. None of those are payroll errors — the payroll was right — and all of them arrive as filing problems weeks later.
In our home market, Kenya, a calculated payroll run now produces the return files themselves, with the identifiers already in them, and a readiness list that names every employee missing a tax PIN, scheme number or national ID — and an employer number left blank — before the file is downloaded. The person filing still uploads each file to the authority’s portal; the system files and remits nothing.
What a monthly filing actually requires
The two rows every product handles are the two that look hardest. The two that took the afternoon are now the ones the record answers, so long as the numbers have been entered — which is what the readiness list checks.
The general principle, which outlives any one scheme
Every jurisdiction has this shape. There is a calculation, there is an identifier the calculation is filed under, and there is a submission. Products compete on the calculation, because it is visible and demonstrable.
The identifier is boring. It is a text field. It never appears in a demonstration and it is the reason a correct payroll produces a rejected filing.
So the question worth asking of any payroll product, in any market, is not whether it computes your deductions. It is whether it holds every field that appears on the submission — and the way to find out is to put the submission form beside the employee record and compare them line by line. We should have done exactly that before publishing the first version of this page.
Four questions about payroll identity
Show me an employee's scheme number on their record.
A good answer sounds like
A field with a value.
What it actually means
Ten seconds, and definitive. Ours shows it masked, with a reveal that is logged.
Does the return file carry it?
A good answer sounds like
Yes, as a column.
What it actually means
If not, somebody enriches the export every month, and that step is invisible until it is wrong.
Which fields on the submission form does the system not hold?
A good answer sounds like
A short list, and they know it.
What it actually means
The right question, and it is answerable by comparing two documents rather than by trusting anybody.
Is there a portal submission, or an export?
A good answer sounds like
An honest answer.
What it actually means
Ours is an export, in every market. Submission integrations are per-authority builds and should be priced as such.
What AWRA OpsHub does today
- Statutory deduction calculation, maintained as a rule set for the home market.
- Statutory identifiers per employee, labelled per country, encrypted at rest, masked on screen and revealed through an audited action.
- Employer tax and social-security numbers held once, in HR settings.
- For the home market, return files built from a calculated payroll run, with a readiness list naming every missing employee or employer identifier.
- Payslip generation and distribution, and payroll posting into the cross-module payments register.
- Employee records that exist independently of user accounts, so staff without logins are still paid and rostered.
More we can add to your workspace
- Portal submission to any authority, in any market, with a receipt coming back.
- Return files in other authorities’ prescribed formats, on the pattern the home market’s now follow.
- A maintained statutory rule set outside the home market — everywhere else is configured by hand.
Where we point you to a specialist
- The first version of this page was wrong about our own product: an audit searched two legacy columns and not the store that replaced them. We say so on the page rather than quietly rewriting it, because the method failure is the more useful lesson.
- The identifiers named as evidence here belong to the home market’s schemes. This page asserts nothing about any North African scheme, rate or filing rule — the argument is the general one about identity versus arithmetic.
- We do not file or remit on your behalf in any market. A return carries the employer’s declaration, and the upload stays with you.
What we can build for Egypt on top of the standard product
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point for Egypt, not a limit on what AWRA OpsHub can do there. Kenya's eTIMS integration and its maintained payroll engine are in the product because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If ETA e-invoicing, an Arabic right-to-left interface, a bank or mobile money feed, a statutory return format, a rule specific to how your operation runs, or a link to a system you already have is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
ETA e-invoicing and e-receipts
Document structuring to the prescribed format and submission against the Authority's interface, including the part vendors skip — rejection handling, resubmission, and a daily report of sales with no registration identifier.
Arabic interface, banks and payments
Arabic text with right-to-left layout and bilingual document templates, plus bank feeds and local payment gateways wired into the Payments Register.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
An Egyptian payroll engine with income tax bands and social insurance contributions, producing schedules in the layout your filing body expects rather than a spreadsheet rebuilt each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedOur position
Before you evaluate any payroll product on its calculation, put your submission form next to its employee record and check every field appears in both. The arithmetic is the part everybody gets right. The identity fields are the part that decides whether your month-end is a download or an afternoon — and the check is worth running against a vendor’s own claims, ours included.
Compare the two documents
The submission form and the employee record. Line by line. It takes twenty minutes and it is the most predictive payroll evaluation you can run.
Talk about payroll fitFrequently asked questions
Where do scheme numbers go for a market you do not label?
Custom fields on employees work and export, and are the sensible interim answer for an identifier we have not labelled for your country. Adding a market’s identifiers to the statutory store is small work, and it is what lets a return file carry them later.
Does the payroll calculation itself work outside the home market?
The engine computes what you configure. What is maintained for you is the home market only; every other market is rates and rules you set up and keep current yourself, which is a real ongoing commitment rather than a setup task.
Would you build a portal submission?
It is exactly the kind of work that gets commissioned, and it is per authority — each one has its own format, its own credentials and its own failure modes. It is scoped as an integration rather than a setting, and we would say so before quoting.
