ERP Requirements Consultant, UK

The sections of a UK ERP requirements specification

The outline I use for UK businesses follows the flow of work rather than the org chart: order to cash, purchase to pay, stock and warehousing, projects or production where relevant, period-end and VAT, management reporting, then the cross-cutting sections for security, hosting, interfaces and data. Each section opens with a few sentences on the current process and the intended one, then lists numbered lines.

A line is only accepted into the document if it meets four tests:

• It describes one behavior, not a bundle of three.
• It names who needs it and in which step.
• It carries a priority of Must, Should, Could or Won't for this phase.
• It has a condition that a tester could observe, such as a document produced, a posting made or a block applied.

Priority is a business call, so I describe it in plain terms during workshops. Must is reserved for lines without which you could not trade, pay people or file. Should covers lines where a manual route exists but wastes time. Could is for conveniences you would take if standard. Won't records what has been knowingly deferred, which protects the budget when the same idea resurfaces mid-project.

The general approach to capturing these lines is set out under ERP requirements gathering; this page is about the document itself.

Writing MTD, VAT and Peppol lines that can be tested

Tax lines fail when they are written as aspirations. "Must be MTD compliant" cannot be tested; a vendor will simply say yes. I break it down into observable conditions and then ask your accountant or tax advisor to confirm or correct each one. I do not determine VAT treatments.

• Submission. The system must file VAT returns through an HMRC-recognized connection, or pass figures to bridging software, without anyone retyping numbers between the ledger and the submission.
• Digital links. Every step between transaction records and the return must be connected digitally, including any spreadsheet adjustments your advisor accepts.
• Return support. A drill-down from each box on the return to the underlying transactions, available to the person preparing it.
• Special treatments. Domestic reverse charge, partial exemption or import VAT handling, listed only where your advisor says they apply.
• Northern Ireland goods. If you move goods between Northern Ireland and the EU, a flag that separate rules may apply, for your advisor to define.

E-invoicing deserves its own group. The UK government has signaled a move toward wider business e-invoicing, with Peppol the framework most discussed, and some public sector buyers already accept or ask for Peppol invoices. I write readiness lines covering sending and receiving through an access point, invoice data quality and exception handling. Your team then sets the priority after checking the current position with your advisor.

Payroll postings, statutory accounts and record keeping

Payroll in many UK businesses runs in dedicated software or with a bureau that handles RTI submissions to HMRC. The ERP specification should not pretend otherwise; it should define the boundary. I write the interface lines that matter to finance:

• How the payroll journal arrives, how often and in what format.
• How costs split by entity, department, cost center or project, including employer pension and national insurance postings.
• Who reconciles the payroll control accounts, and which report proves the journal matches the payroll provider's totals.
• Whether timesheet or expense data must flow from the ERP to payroll, and who owns corrections.

Statutory accounts are usually prepared by your accountant, under UK GAAP or IFRS as they advise. The specification therefore asks for what they need from the system: a trial balance by entity, a mapping to their account format, period locking and an export they can work with. Where a group consolidates, the lines cover intercompany matching and the currencies involved, typically sterling alongside euro or dollar.

Record keeping lines state how long data must stay retrievable, based on the period your advisor gives you, how closed periods are protected from change and how data can be exported in full if you leave the platform. These lines tend to be skipped because nobody owns them; the specification assigns an owner to each.

Hosting, UK GDPR, access, interfaces and data migration

Non-functional lines are where vendors answer most loosely, so I write them as direct questions with an expected form of answer:

• Data location. Where production data and backups are held, whether a UK or EEA region is offered and what safeguards apply to any transfer outside it. How UK GDPR applies to your data is for your data protection lead or counsel to judge.
• Access. Single sign-on, role design, restriction by company or site, and a documented process for removing leavers.
• Audit trail. Which records log field-level changes, who can view the log and how long it is kept.
• Performance and support. Expected response during month-end and peak trading, support hours that cover the UK working day and how outages are communicated.

Each interface gets a short card: systems, direction, trigger, frequency, data owner and what happens when it fails. For UK businesses that list commonly includes bank statement imports and BACS payment files, Direct Debit collections, eCommerce or marketplace orders, CRM and a reporting tool.

Migration lines define which records move, how much history, who cleans customer, supplier and item data, and how opening balances and open VAT periods are reconciled and signed. Writing "vendor to advise" here simply defers a cost until after signature.

Traceability, contracts and gaps that weaken UK specifications

The specification is most useful when its IDs travel. In the register, every line carries three cross-references: where a vendor showed it in a demo, how each candidate platform scored on fit, and which acceptance test signs it off. In a tender, partners answer the requirement annex line by line; the UK ERP selection page explains how those answers and demos are then scored. When a partner is chosen, their statement of work can cite the signed version or their answers to it, which gives delivery and acceptance a common text. The RFP consulting page covers the annex format.

Version control is simple but strict: a version number, a dated change log entry for every edit after baseline, the reason, the approver and the tests affected. Each process owner signs their section; the sponsor signs the whole.

Gaps that put UK specifications at risk include:

• MTD reduced to a single line, leaving bridging or connector costs unpriced.
• No Peppol position at all, so the question arrives later as a change request.
• Payroll postings omitted, creating reconciliation work at the first month-end.
• Hosting and transfer questions left to the contract stage.

All of this runs remotely in UK business hours, with visits by arrangement and no commissions from any vendor. For process maps and fit-gap work around the document, see the UK ERP business analyst page, or the UK ERP consultant page and the UK hub for wider context.