What Does This Obligation Count In?
Twice a year a third pay day lands in one month. If your system has one slot per month, the question is not what it does with the third one — it is whether anybody finds out.
When a business enters a new market, the question everybody asks about tax is "what is the rate". It is the wrong first question, or at least the least useful one — a rate is a number, and numbers are easy to change.
The better question is: what is this obligation computed over? Per what. Per invoice, per payment, per month, per fortnight, per employee, per state, per sector. Because the unit is not a setting — it is a shape, and if your system's shape is wrong the arithmetic cannot be corrected by editing a figure.
We learned this the direct way. Two of our own defects came out of asking it about one market, and both were in a table definition rather than in a feature list.
Defect one: a fortnight is not half a month
Where a deduction is computed from a fortnightly table, the input has to be a fortnightly figure. Derive it instead from a monthly gross and halve it, and you get a number that is close, plausible, wrong, and wrong in a direction that depends on the shape of the table rather than on anything a reviewer would notice.
It is close enough that nobody queries it. That is what makes it dangerous rather than merely incorrect: an error of a few percent on every pay packet, every cycle, with no symptom other than a figure somebody might describe as roughly right.
Defect two: twenty-six does not fit into twelve
A fortnightly cycle produces twenty-six pay days a year. Twice a year, that means three pay days land inside one calendar month.
A system whose period is the month has one place to put a month's payroll. Two payments fit. The third has nowhere to go — and what happens next is not a crash, which is the whole problem. Something gets overwritten, or merged, or rejected in a way somebody works around by adjusting the month before. The month still balances. The year is short by a payment nobody can find.
Why we are publishing this rather than fixing it quietly
Because a vendor's country list is not evidence, including ours, and the fastest way to demonstrate that is to show you where our own reference data and our own period handling were wrong. Both of these were found by asking what the obligation counts in — not by a test, not by a customer, and not by a review of the feature list. If we had found them and said nothing, the page would read better and be worth less.
The general form, which is worth more than either defect
Every obligation counts in something. Get the unit wrong and no amount of correcting the rate will save you.
| The unit | A market where it bites | What a wrong assumption produces |
|---|---|---|
| A fortnight | A fortnightly deduction table | A plausible figure, wrong every cycle |
| A payment, not an invoice | A threshold measured at settlement | A deduction decided at the wrong moment |
| A sector, not a country | A rate that varies by what you do | A default that is wrong for your entire business |
| A state, not a nation | A tax administered sub-nationally | One national rate that applies nowhere |
| Another levy, not the net | A charge computed on a base including another charge | A total that is short by a compounding |
| A port, not a border | Separately administered points of entry | One landed cost describing two consignments |
Ask "what is the rate" and you learn a number. Ask "per what" and you find out whether your system can hold the answer at all.
How to ask it, before you buy anything
This costs an hour and it is the highest-value hour in an evaluation. It is also a question a vendor will not have rehearsed.
- For each obligation that matters to you: what is it computed over? Get the unit named, not the rate.
- Ask the vendor to show you where that unit is stored — the field, not the report.
- Ask what happens at the boundary: the third pay day, the month with five weeks, the year with an extra cycle.
- Ask what happens when two of the thing exist where the system expects one — two rates, two ports, two currencies, two pay days.
- If the answer is "that has not come up", you have found the shape of the next defect and it is better to find it now.
What we do and do not claim in this market
Plainly, because the post has spent its length on our own errors and the boundary matters. We do not maintain a Papua New Guinean statutory payroll engine — no tables, no bands, no filing — and this post does not tell you what any obligation is. Our maintained statutory engine covers Kenya only, which is also the evidence a second one is possible and commissionable with a written specification, a timeline and a price.
What runs here is the operation: multi-site stock including goods you do not hold, a receipt that stays open across a long import chain, supplier documents with dates the system watches, and cost coded to a job as it is entered. The full division is on the Papua New Guinea market page, and the offline half of operating here is four things you can do with no signal.
What is not built for Papua New Guinea 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 Papua New Guinea. 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 a fortnightly pay cycle, a PNG payroll engine, supplier compliance dates at payment time, 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.
A pay period that is not a calendar month
The first build here is not a tax pipeline, because there is no clearance regime to connect to — it is a payroll period that can be a fortnight. Today our payroll run is one calculation per organization, per calendar month, per country of work, enforced by a unique key on the table and assumed again in the timesheet lock, the period-end resolution, the attendance window and the run form. Papua New Guinea pays twenty-six times a year and twice a year a month needs three runs, so this is a data-model change rather than a setting, and we would scope it as one. Then salary and wages tax on fortnightly tables, and the statutory deductions, computed on live employee records.
Supplier compliance dates, banks and payments
An expiry-dated compliance status on the supplier record that the payment run actually reads, so a business payment to a supplier whose Certificate of Compliance lapsed last week is flagged before it leaves rather than found in a review — we hold the document today and do not act on it. Plus bank feeds and local payment rails wired into the Payments Register. We do not verify a certificate and never will; validity is the Commission's determination.
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
A Papua New Guinean payroll engine: fortnightly salary and wages tax tables, superannuation and the training levy computed on live records, with the twenty-sixth pay period of the year recorded as its own event rather than folded into a month that already has two.
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 integrated