Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
For Papua New Guinea
Salary and Wages Tax is computed on fortnightly tables, so the fortnight is the statutory unit rather than a scheduling preference — twenty-six of them in a year, against twelve months that do not divide into them. Twice a year a month therefore contains three pay days, and which two months depends on where your cycle starts. Our payroll run is stored as a seven-character month with a unique key on it, which means a second run inside one month is not missing from the roadmap: it is refused by the database. The line of code is below, and so is the year, worked through.
The cycle, as arithmetic
Twenty-six pay days and twelve months, laid over each other. Every cell below is a calendar month and every mark in it is a pay day. Two cells have three marks, and no arrangement of a fortnightly cycle avoids that — it is what 26 against 12 means.
Jan
3
Feb
2
Mar
2
Apr
2
May
2
Jun
2
Jul
3
Aug
2
Sep
2
Oct
2
Nov
2
Dec
2
The last two rows are the page. Two months a year need three pay runs and the database will accept one, and because 26 and 12 share a factor of two, the collision is not random — the clocks realign every six months, forever. This is not a scheduling inconvenience that a determined administrator works around. The tax on a fortnight is computed from a fortnightly table, and a month is not two fortnights.
The limit, quoted
One line, and it is not a missing feature. It is a constraint that makes the feature impossible without a schema change.
From the migration, verbatim
$table->string('period', 7); // 'YYYY-MM'
$table->unique(['tenant_id', 'period', 'work_country']);
database/migrations/2026_07_12_000013_create_payroll_runs_table.php
Read the second line as a sentence: one payroll run, per organization, per month, per country.
And the month is assumed four more times downstream
timesheet_periods
The same seven-character period, with its own unique key per employee per month.
Payroll refuses to calculate without a LOCKED timesheet period, so the monthly assumption is enforced a second time on the same pay run — fixing one table would not be enough.
PayrollCalculationService
The period end is derived as the last calendar day of the month.
Every figure resolved as of period end — compensation in force, statutory rules in force — is resolved at a month boundary that a fortnightly cycle does not have.
AttendanceInputResolver
Attendance and unpaid leave are gathered from the first calendar day of the month.
The window the hours are read from is a month, so even a correctly split pay run would be reading the wrong span of days.
The run form
The period is validated against a four-digit year and a two-digit month.
There is no input that could express a fortnight even if everything below it could store one.
Our payroll module runs one calculation per organization, per calendar month, per country of work. That is not a default that can be changed in settings and it is not a gap in a feature list — the period is a seven-character string, the month is baked into how the period start and end are computed, and a unique key refuses a second run in the same month at the database. We measured this on 2026-08-10 by reading the migration rather than by reasoning about the product, and there is a test in the repository that pins the behaviour so that changing it has to be a deliberate act.
The consequence for a fortnightly market is total rather than partial. Twenty-six pay events cannot be recorded as twenty-six payroll runs, and the two months a year that need three cannot be recorded at all. There is no configuration that helps and no workaround we would recommend, because every workaround we can think of ends with a pay event recorded against the wrong period and a salary and wages tax computed from a monthly figure that the statutory table does not use. So we will say the plain thing: we are not your payroll system in Papua New Guinea today. What that is worth as a disclosure is that everything else on this page is measured to the same standard.
What this costs today
Each of these is a record in the wrong period or a decision made without a document that existed. Nothing errors, nothing refuses, and the difference is found much later by somebody reconstructing a year.
Twice a year the third pay day of a month arrives and the system has one slot for the month. It gets merged into the second run, or booked as an adjustment, or entered in a spreadsheet and journalled in — and from that moment the payroll ledger and the bank no longer describe the same events.
Salary and wages tax comes from a fortnightly table. Derive it from a monthly gross and the progressive steps land in different places, which is not a rounding difference — it is a different figure, in a direction that depends on the employee. It reconciles at the year only if somebody reconciles it.
What you must withhold from a business payment turns on whether the payee holds a current Certificate of Compliance. The certificate has an expiry date, it lives in an email or a folder, and nothing joins it to the payment run. The deduction is therefore correct until the day it silently is not.
Freight to a coastal port, coastal shipping, road haulage inland, handling at each transfer — invoiced separately and weeks apart. If the receipt closed when the goods arrived, none of it reaches the unit cost, and the margin on a job is calculated from a number that was never the cost.
What we are actually for
Everything below is running today. Payroll is not on this list and the section above explains why in more detail than a vendor normally would.
Freight, port charges, coastal shipping, inland haulage and handling attach to the consignment when the invoice arrives rather than when the goods did, and the unit cost recalculates. In a market where a single delivery is three or four separate carriers billing at different times, an open receipt is the difference between a cost and an estimate.
A yard, a camp store, a site container and a coastal warehouse are four locations with confirmed transfers between them and counts against each. Goods in transit for a week between two of your own places is the normal case here rather than the exception, and it is the case most systems record as an instant.
Transfers, cash and card settlements in one place with the invoices each one clears and the documents held against them. Where a deduction is decided at payment time by a document rather than by an amount, the payment is the only level the question can be asked at.
Certificates, registrations and approvals held against the supplier and previewable in place rather than filed by whoever received them. We do not judge whether a certificate is valid — that is the Commission's business — but a document with a date on it, in the record, ahead of the payment run, is the whole of what an operations system can honestly offer here.
Project, site, cost centre and customer captured at entry rather than reconstructed at reporting time, which is what makes per-site and per-contract cost a filter instead of an excavation. For contract and resource work it is usually the reason the system is bought.
A purchase invoiced in Australian or US dollars and settled in kina keeps both amounts and the genuine rate on the transaction, so a margin can be explained months later rather than recalculated from a rate nobody wrote down.
Scope, in three parts rather than two
Three columns, because "no" means two entirely different things and one list hides which is which. The middle column is work that has not been done and has a price. The right-hand column is work we would decline from a paying customer — and it is the one to demand from every other vendor on your list, because a page without it has not told you where its edges are. The first item in the middle is a constraint in our own database rather than a missing feature.
Running in the product today
On the roadmap — and commissionable now
Not ours, by choice — and this column is the reason to believe the other two
Nothing in the middle column is a permanent limit, and the first item is the one we would want to fix regardless of whether you buy. Kenya's eTIMS transmission and its maintained statutory payroll engine both exist because Kenyan clients needed them and commissioned them; neither appeared on its own. A fortnightly pay cycle is a bigger change than either, because it moves a unique key and four downstream assumptions rather than adding a feature beside them — which is exactly why we would rather tell you the size of it than discover it in month three. If the pay cycle, a PNG payroll engine, or supplier compliance dates at payment time is what stands between you and a decision, say which and we will scope it as a build: written specification, timeline and price, before you commit to anything. What we will not do is print a date on this page that nobody has paid for.
Read the three columns rather than counting them. The middle one is work, and work has a specification, a timeline and a price. The right-hand one is where we stop on purpose, and it is the column worth demanding from every other vendor on your list — a page without one has simply not told you where its edges are. One thing that is deliberately absent from all three: language. English is an official language here and the language of business, so unlike our Francophone and Gulf pages there is nothing to disclose, and we are not going to pad the list to look thorough.
How this starts
Not the pay days — the runs your system recorded. If twenty-six pay events produced twenty-four records, you have found the subject of this page in your own data, and the two months where the arithmetic went is where the difference is hiding.
Pick a business payment made last quarter. Find the payee's Certificate of Compliance as it stood on the day you paid, and its expiry date. How long that takes is the measure of the exposure, and it is a filing problem rather than a tax problem.
Payroll and filing are local purchases here and we have said so above with the line of code to back it. What is left is cost, stock, evidence and control — a smaller conversation than most vendors will let you have, and the one we can actually stand behind.
Read before you shortlist
Twenty-six pay days do not fit into twelve months, and the two left over arrive on a six-monthly rhythm rather than by accident. Most finance systems store a payroll period as a calendar month and never mention it.
Almost every finance system stores one tax rate per country and no date. That is correct until the first credit note against a pre-change invoice, and then it is confidently wrong with nothing to warn you.
Ask every vendor how many payroll runs their system accepts in one calendar month, and what reads a supplier certificate's expiry date at payment time. We publish our own answers, which are one and nothing.
Questions we are asked here
No, and it is the first answer here rather than the last because it is the one that matters most. Our payroll module records one run per organization, per calendar month, per country of work, and that is enforced by a unique key on the table rather than by a setting — a second run inside the same month is refused by the database. The month is then assumed again in four places downstream: the timesheet lock is monthly and payroll will not calculate without it, the period end is computed as the last calendar day of the month, the attendance window starts on the first, and the input itself only accepts a year and a month. We quoted the constraint on this page rather than describing it. **It is on the roadmap rather than a boundary, and it is commissionable now** — but it is a data-model change rather than a feature, and we would rather you hear the size of it from us. If this is what stands between you and a decision, tell us and we will come back with a written specification, a timeline and a price before you commit to anything. Kenya's statutory payroll engine exists because a Kenyan client commissioned it, which is the only reason we can make that offer with a straight face.
No. The Internal Revenue Commission takes filings electronically, but invoices are not cleared or transmitted before they are valid the way they are in Kenya, Saudi Arabia or Tunisia. There is no pipeline to be connected to and no accreditation to hold, which means that for once the absence of an integration on our side is not a gap — there is nothing there to integrate with. We mention it because several pages in this cluster spend a long section on clearance and a reader arriving from one of them will look for it here. If that changes, this paragraph changes; we are not going to speculate about when.
The mechanism is the part worth understanding, and it is unusual: what you must deduct from a prescribed business payment depends on whether the PAYEE holds a current Certificate of Compliance from the Internal Revenue Commission. Not on the amount, not on the category of spend — on somebody else's document, and on whether it is in date on the day you pay. We deliberately do not print the rate anywhere on this page, for the same reason we do not print the Tunisian stamp duty: the percentage is the part that moves in a budget and the mechanism is the durable fact. Where we fit is narrow. We hold the certificate against the supplier with its date, we hold the payment with the invoices it cleared, and we keep the two retrievable together. What we do not have yet is an expiry-dated compliance status that the payment run reads, so that a payment to a supplier whose certificate lapsed is stopped before it leaves rather than found in a review. **That one is on the roadmap and commissionable now** — it is a field, a date and a rule at payment time, and it is a small enough build that we would quote it quickly.
No, and nobody selling you software can. A system can show you what is committed and in which currency, how long your settlements have actually taken over the last year, and which suppliers are waiting — which is genuinely useful for planning and for the conversation with your bank. It cannot affect availability, it cannot change an order, and any vendor implying otherwise is describing something that does not exist. **This one is a boundary rather than a backlog, and you should want that answer**, because the alternative is a supplier who will say yes in the meeting and be unable to explain themselves in month four. We argue this at length on our Malawi page and the reasoning carries over without modification.
Partly, and the honest split matters more than the reassurance. What works is that the record of a place does not require somebody at that place: transfers are confirmed by the receiving location, counts are entered when a connection is available, and a site that is offline for two days produces a delayed record rather than a lost one. What does not work is a promise of full offline operation — this is a web application, and a location with no connectivity for a week is a location entering a week of data at the end of it. If genuine offline capture at the point of work is a requirement rather than a preference, say so early, because **it is on the roadmap and commissionable rather than something we would pretend is already there**, and it is a substantial build with a real price.
Because of the item we volunteered rather than the ones we claimed. The page opens by quoting a constraint in our own database that makes fortnightly payroll impossible, names the four places downstream that would also have to change, and there is a test in the repository pinning the behaviour so a fix has to be deliberate. That is checkable in a way a reference story is not, and it is the only kind of evidence a vendor with no local presence has any business offering. The rest is ordinary and we will not dress it up: no office here, no implementation partner, support remote from Nairobi in English with about three hours of overlap with your working day. Ask us what happens when the person who implemented your system leaves — and ask the same question of every vendor whose page has nothing on it they would rather you did not read.
Yes, and this is the half of the market we are genuinely for. Duty, GST at import, port and handling charges, coastal shipping and inland haulage attach to the consignment as their invoices arrive rather than only at receipt, and the unit cost recalculates each time. Where a single delivery involves three carriers billing weeks apart, that open receipt is the whole difference between a landed cost and an estimate. What the system will not do is tell you whether a particular import is exempt or at what rate — that is a question for your accountant and the Commission, and we hold the rate you configure rather than an opinion about it.
We can give the group consistent operational figures — cost by site, by project and by cost centre, in kina and in the currency the transaction actually happened in, on the same basis every month. What we do not do is produce a statutory consolidation or anything an Australian or New Zealand filing obligation would accept, and we have deliberately not written pages for either market. **That is a boundary rather than a backlog and the reasoning is worth stating**, because it also tells you what we are: a group with a real Australian reporting obligation should be buying that capability from somebody with an Australian bench, and we would rather sit under it as the operational layer than pretend to replace it.
Twenty-six pay days, and the number of payroll records your system actually produced. Bring the difference and we will tell you honestly which half of your problem we are for — the page above should already have told you which half we are not.