Buying Operations Software in Papua New Guinea: A Straight Guide
Ask every vendor on your list how many payroll runs their system will accept in one calendar month. We publish what ours does, which is one, which is the only reason the question is fair coming from us.
Most buying guides for this market are written by people who have never had to record a third pay day in a month, and they spend their length on modules. This one is organised around the two questions that actually separate the software that will work here from the software that will look like it does: what your system thinks a pay period is, and what it does with a supplier document that has an expiry date on it.
A note on where we stand, because it should change how you read the rest. We are a Nairobi vendor with no office here, no implementation partner and about three hours of overlap with your working day. We also cannot run a fortnightly payroll, and the reason is a constraint in our own database that we quote on our market page. Read this as a guide to evaluating anybody, ourselves included, and weight the parts where we are visibly arguing against our own interest accordingly.
Question one: how many payroll runs in a calendar month?
Salary and wages tax here is computed on fortnightly tables. That makes the fortnight a statutory unit rather than a scheduling habit, and it has an arithmetic consequence nobody mentions in a demo: twenty-six pay days in a year against twelve months, which do not divide. Twice a year a calendar month contains three pay days, and which two months depends entirely on where the cycle starts.
So the question to ask is not "do you support fortnightly payroll", to which everybody says yes. It is "how many payroll runs will your system accept for one company in one calendar month?" Ask it as a storage question. A product can display a fortnightly schedule perfectly happily while writing the results into twelve monthly buckets, and the difference only surfaces in the two crowded months.
Our own answer, so the question is fair
One. Our payroll run is one calculation per organization, per calendar month, per country of work, and there is a unique key on the table enforcing it — a second run in the same month is refused by the database rather than missing from a backlog. The month is then assumed again in the timesheet lock that payroll requires, in the period-end resolution, in the attendance window and in the run form. We are not your payroll system in Papua New Guinea today. It is on our roadmap and it is commissionable, and it is a data-model change rather than a feature, which is why we would rather quote you a size than a date.
Question two: what happens to a supplier certificate that expires?
What you must withhold from a prescribed business payment turns on whether the payee holds a current Certificate of Compliance from the Internal Revenue Commission. Read that again as a software requirement, because it is an unusual one: the correct amount to pay is decided by somebody else's document, and by whether that document is in date on the day you pay.
We deliberately do not print the rate anywhere in this guide. The percentage moves in budgets and the mechanism does not, and the mechanism is what your system has to be able to model. Your accountant has the current figure.
Almost every system on your list will "support" this in the sense that you can attach a PDF to a supplier record. Very few will do the thing that actually prevents the error, which is to hold the expiry date as data and read it at the moment a payment run is prepared. The gap between those two is where the exposure lives, and it is invisible in a demo because a demo never runs a payment batch two weeks after a certificate lapsed.
- Is the certificate a document with a date field, or a file attachment with a filename?
- Does anything read that date at payment time, or only when somebody opens the supplier record?
- Can you produce, today, a list of suppliers whose certificate expires in the next sixty days — as a report rather than as a folder trawl?
- When a payment is made to a supplier whose certificate had lapsed, is that discoverable afterwards from the payment record, or only from the supplier record as it stands now?
- And the one nobody asks: who does the vendor say decides validity? Anyone who answers "our system checks it" is describing a check they do not perform.
Where we stop, on purpose
We hold the certificate against the supplier, we hold its date, and we make both retrievable next to the payment. We do not verify it and we never will — validity is the Commission's determination and the supplier's document, and a vendor who offers to verify compliance status is describing something they cannot do while carrying none of the liability when it is wrong. What we do not have yet is an expiry-dated compliance status that the payment run itself reads. That is a field, a date and a rule, it is genuinely small, and it is on the roadmap and commissionable now.
The question that is not on most lists: is there anything to integrate with?
If you have read buying guides for Kenya, Saudi Arabia or Tunisia, you will have arrived expecting a long section about clearance pipelines. There is not one, because there is no invoice-clearance mandate here. The Commission takes filings electronically; invoices are not validated before they are valid.
That is worth saying plainly for two reasons. First, it means the absence of a tax integration on a vendor's feature list is not a gap in this market — there is nothing there to integrate with, and a vendor selling you a pipeline against a regime that does not exist is selling you a line item. Second, it changes what the compliance conversation should be about: not transmission, but whether your records can answer a question later, which is a much less glamorous requirement and a much more useful one.
The operational half, which is where the money usually is
The reason most businesses here actually buy an operations system has nothing to do with tax. It is that a delivery to a site involves several carriers billing at different times, and the cost of the goods is therefore not known on the day the goods arrive.
| What arrives | When it is invoiced | What happens if the receipt has closed |
|---|---|---|
| The goods | Day one | Booked at supplier price. This part is easy and everybody does it. |
| Ocean freight and port charges | One to three weeks later | Lands in a freight expense account, attributed to nothing. |
| Coastal shipping or a charter leg | Whenever the operator invoices | Same, and usually larger than anybody expects. |
| Inland haulage to site | After delivery, sometimes much after | Same again — and this is frequently the biggest single component. |
| Handling at each transfer | Irregularly, in small amounts | Disappears entirely into miscellaneous. |
So the operational question to ask a vendor is: can a cost invoiced three weeks after receipt still reach the goods it belongs to and change the unit cost? If the answer involves a journal entry, the answer is no.
Eight questions for every vendor on your list
Including us, and we have answered all eight above
"How many payroll runs will your system accept for one company in one calendar month?"
What you will hear
"As many as you need" — or a pause.
How to read it
The pause is the honest answer. Ask for it as a storage question: what column holds the period, and is there a unique key on it? A vendor who cannot answer that has not looked.
"Show me a payroll period that is not a calendar month."
What you will hear
A schedule screen, usually.
How to read it
A schedule is a display. Ask what the stored period is called and what shape it has. This is the single most useful five minutes of the whole evaluation.
"Where does a supplier's Certificate of Compliance expiry date live?"
What you will hear
An attachment, or a custom field.
How to read it
A custom field is a good answer if something reads it. Ask what reads it and when. "You can see it on the supplier screen" means nobody reads it at payment time.
"Can a freight invoice arriving three weeks after receipt change the unit cost of the goods?"
What you will hear
Yes, or a description of a journal entry.
How to read it
A journal entry corrects the accounts and leaves the unit cost wrong, which means every margin report built on it is wrong in the same direction. These are not the same answer.
"What is your integration with the Internal Revenue Commission?"
What you will hear
Ideally, "there is nothing to integrate with."
How to read it
That is the correct answer and an honest vendor gives it. A confident description of a clearance pipeline is a description of a market that does not exist here.
"Who in your organisation has been to Papua New Guinea?"
What you will hear
A name, or a straight no.
How to read it
Either is acceptable. Our answer is nobody. What is not acceptable is a vague claim of regional presence that resolves to a reseller agreement signed once.
"What are your support hours in my time zone, on a Tuesday?"
What you will hear
A specific window, or vagueness.
How to read it
Vagueness here always resolves badly. Ours is about three hours, at the end of your afternoon, and it is asynchronous outside that. Get the number, not the adjective.
"What happens when the person who implemented this leaves your company?"
What you will hear
Documentation, or a shrug.
How to read it
The single best question in any software evaluation, and the one most likely to produce an honest answer, because nobody has a rehearsed one.
Two things no vendor can sell you
Foreign currency availability is the first. A system can show you what is committed, in which currency, and how long your settlements have actually been taking over the past year — genuinely useful for planning and for the conversation with your bank. It cannot affect availability or ordering, and any pitch implying otherwise is describing something that does not exist. We have argued this at length on our Malawi page rather than repeating it here, and the reasoning carries over unchanged.
The second is a judgement about your own arrangements. Resource and contract operations here carry obligations that are negotiated rather than uniform, and no vendor has read yours. A system can hold the costs and the evidence against the project they belong to. What the agreement requires is a question for the people who signed it.
The pay cycle is the first build here, and it is bigger than a feature
"Not built in" describes what ships in the standard product, not the limit of what AWRA OpsHub can do here. Kenya's eTIMS integration and its maintained statutory payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open. But the ordering and the honesty about size both matter in this market: a fortnightly pay period moves a unique key and four downstream assumptions rather than adding a feature beside them, so it is the first thing we would build and it is not small. If it is what stands between you and a decision, tell us and we will scope it as a build — written specification, timeline and price — before you commit to anything.
A pay period that can be a fortnight
The period, the unique key, the timesheet lock, the period-end resolution and the attendance window — all five, because fixing one changes nothing. First, because everything else in payroll depends on the unit being right.
A PNG payroll engine
Fortnightly salary and wages tax tables, superannuation and the training levy computed on live employee records rather than rebuilt each period.
Supplier compliance dates at payment time
An expiry-dated compliance status on the supplier that the payment run reads, so a lapsed certificate is flagged before the payment leaves. Small, well-defined, and nobody has asked for it yet.
Commission output
Returns, schedules or remittance files in a format the Commission accepts, generated from the records rather than re-keyed from them.
Support inside your working day
A staffing decision rather than an engineering one, and quotable like any other. Today the overlap is about three hours and we would rather you priced that in than discovered it.
One thing deliberately absent from that list, because you will notice its absence on the equivalent lists for our Francophone and Gulf pages: language. English is an official language here and the language of business, so there is nothing to disclose, and we are not going to pad a scope list to look thorough.
The short version
Two questions decide this market and neither is on a standard evaluation template. How many payroll runs will the system accept in one calendar month, and does anything read a supplier certificate's expiry date at the moment you pay. Ask both as data questions rather than feature questions. Our answers are one, and no — the first is a constraint we publish, the second is a small build nobody has commissioned. Everything after those two is the ordinary business of cost, stock and evidence, and it is where the money usually is.
Count last year's pay runs
Twenty-six pay days, and the number of payroll records your system actually produced. Bring the difference and we will tell you plainly which half of your problem we are for, and which half we are not.
Talk to us about Papua New Guinea