ERP Requirements Consultant, Australia

How the specification is laid out for an Australian business

I lay out the document in the order money and work move through the business: sales or jobs through to invoicing and cash receipts, purchasing through to supplier payment, stock and warehousing, project or field delivery, period-end and BAS, then reporting. Cross-cutting sections follow for payroll interfaces, hosting, security, integrations and migration.

Every line follows one pattern so it can be quoted, demonstrated and tested:

• ID and area for citation in tender responses and contract schedules.
• A single behavior in plain words, never three requirements joined by "and".
• MoSCoW priority decided by the business owner, not the loudest voice.
• Acceptance condition stating the evidence a tester will look for.
• Owner and advisor where an accountant, BAS agent or lawyer has confirmed the wording.

I explain the priorities in words rather than targets. A Must is something without which you cannot trade, pay staff or lodge. A Should has a workable manual route that costs time. A Could is a convenience to accept if the platform offers it in standard. A Won't is a conscious deferral, written down so it does not slip back in as scope halfway through the build.

The workshop method behind the content is on the ERP requirements gathering page. Process mapping and fit-gap analysis for Australian operations sit with the Australian ERP business analyst service.

GST, BAS, ABN and Peppol lines that pass or fail

A line such as "must handle GST" is something every vendor will tick. I break tax and invoicing into conditions a tester can check, then your accountant or BAS agent signs off the wording. Setting your GST treatment is not my role.

• Tax codes. The system must apply the tax codes your advisor defines for taxable, GST-free, input-taxed and imported transactions, with defaults by item and by customer or supplier.
• Tax invoices. Customer invoices must carry the details your advisor confirms a valid tax invoice needs, including your ABN.
• BAS support. A report mapping tax codes to BAS labels, with drill-down to source transactions for whoever prepares the lodgment.
• Supplier ABNs. ABN captured on every supplier, checked against the public register where the platform allows, and the withholding treatment your advisor sets for suppliers who do not provide one.
• Industry reports. If your advisor says the taxable payments annual report applies to your industry, the payments data it needs.

Peppol earns its own group. Australian government agencies can receive Peppol e-invoices, and some larger buyers ask suppliers to use it. The readiness lines ask whether the platform can exchange invoices via a Peppol access point, how it validates outgoing invoice data and what users see when a message bounces. Whether these are Must or Should depends on your customers and on any change in policy, which your advisor should confirm when the specification is baselined.

Payroll, STP and super: defining the boundary

Many Australian businesses run payroll in dedicated software that handles Single Touch Payroll reporting, award interpretation and super payments through a clearing house. The ERP specification should state that boundary clearly instead of leaving it to the partner to assume.

The payroll section I write typically covers:

• Inbound journal. Format, frequency and the split by entity, state, cost center or job, so labor cost lands where managers expect it.
• Withholding and super liabilities. Which clearing accounts receive PAYG withholding and super amounts, and the report that reconciles them to payroll totals before the BAS is lodged.
• Payroll tax. If your advisor confirms payroll tax obligations in one or more states, the data the ERP must hold to support the calculation or reconciliation.
• Timesheets. Whether hours captured against jobs in the ERP must flow to payroll, and who corrects them when they are wrong.

Record retention fits here too. The specification states how long financial and payroll-related records must remain retrievable, based on the guidance your advisor provides, how closed periods are locked and how complete data can be exported if you later change platform.

Currency lines are usually short: AUD as functional currency, with NZD, USD or other currencies for import costs, export sales or a New Zealand entity, and the revaluation and bank account needs that follow.

Hosting, privacy, access, integrations and migration

Lines about behavior rather than function are easy for vendors to agree with vaguely, so I frame each one as a question that needs a written answer:

• Onshore or offshore. The country holding live data and backup copies, the option of an Australian region, and any customer or government contract that insists on one.
• Privacy. What the vendor does to help you meet the Privacy Act and the Australian Privacy Principles, as your lawyer interprets them.
• Who can see what. Login through your identity provider, permissions by company and site, prompt lockout of departing staff and a log of edits to ledgers, customers, suppliers and items.
• Availability. Support cover across eastern, central and western time zones, allowing for states that do not observe daylight saving, plus performance at month-end and during seasonal peaks.

For every connection I note the two systems, which way data flows, what starts the transfer, how often, who looks after it and how errors are caught. A typical Australian list includes bank feeds and ABA payment files, the payroll journal, eCommerce or marketplace orders, a job or field service app being retired or kept, and a reporting tool.

Migration requirements state which records move from Xero, MYOB or the current add-ons, how much history is needed, who tidies the master records first, and how opening balances, GST control accounts and work in progress on open jobs are agreed before anyone signs.

Traceability, tender use, sign-off and common specification gaps

The specification's IDs carry through every later stage. The traceability register gives every line three companions: the scripted demo moment where a partner has to prove it, a fit verdict for each shortlisted platform and the UAT case that eventually closes it. The Australian ERP selection page describes how those scripted demos are scored, while the annex partners fill in line by line is explained under ERP RFP consulting. When contracts are drawn up, the partner's scope document can cite the exact specification version, tying build and acceptance to the same wording.

Post-baseline edits need a brief change note stating the line affected, the reason, the approver and any test that has to be rewritten; the log keeps each note and the version moves up. Area owners sign their sections and the sponsor signs the baseline as a whole.

Gaps that put Australian specifications at risk include:

• BAS reduced to one line, with no label mapping or drill-down defined.
• No payroll boundary, so STP and super reconciliations surface during the first close.
• Peppol never discussed, leaving cost and priority to be settled after signature.
• Add-on app data overlooked in migration scope.

The work is remote, scheduled in hours that suit your main state, with visits by arrangement. Vendors and partners pay me nothing for recommendations or introductions. For wider advice read about ERP consulting across Australia, or go back to the Australian market page.