The Numbers You File Under
This payroll engine computes statutory deductions correctly and cannot store the reference numbers those deductions are filed under. Two such columns exist in our database and are read by nothing — not a form, not a payslip, not an export.
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
Two columns on the employee record for social-security scheme numbers. They exist in the database. They are referenced by nothing anywhere in the application — no form writes them, no payslip prints them, no report includes them, no export carries them.
The tax identifier beside them is properly wired and used throughout. So this is not a policy of not storing identifiers. It is two fields that were added and never connected, sitting next to one that was.
The deduction is calculated to the cent and the system cannot 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.
What a monthly filing actually requires
The two rows the product does handle are the two that look hardest. The three it does not are the ones that take the afternoon.
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.
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 has the column and no field.
Does the payroll export 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.
- A tax identifier on the employee record, wired through forms, payslips and reports.
- 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.
- A configurable working week and holiday calendar driving leave arithmetic.
What it does not do
- Any storage of social-security scheme numbers. Two columns exist and nothing reads them.
- Any employer scheme registration numbers.
- Portal submission to any authority, in any market.
- A statutory return export in any authority's prescribed format.
- A maintained statutory rule set outside the home market — everywhere else is configured by hand.
Not ours, by choice
- This was found by auditing our own schema for this batch and is filed as a priority item. It is two fields on a form and a column on an export, which is why it is priced small and stated plainly rather than explained away.
- The two columns named here are from our own database and belong to the home market's schemes. Nothing on this page asserts anything about any North African scheme, rate or filing rule — the argument is the general one about identity versus arithmetic.
- North Africa is here because payroll in those markets is administered rather than automated, which makes the completeness of an export the thing that determines how long the month-end takes.
What is not built for Egypt today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Egypt. Kenya's eTIMS integration and its maintained payroll engine exist 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 your own operation needs that the standard one does not have, or a link to a system you already run 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 we found two missing in our own schema by looking.
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
Could I use a custom field for a scheme number?
Yes, and it is the sensible interim answer — custom fields on employees work and export. It is a workaround for two fields that should be first-class, and it is worth doing on day one rather than at the first filing.
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.
