Choosing an ERP: Questions to Ask Before You Commit

Most ERP decisions get made in a demo room. The software looks capable, the presenter is fluent, and the proposal arrives a week later with a number attached. What rarely happens in that room is the conversation that actually determines whether the project succeeds — because the decisive questions are almost never about features. They are about scope, data, access, and what happens in month seven, when the excitement has worn off and the system has to carry a real month-end.

Start with the processes you are not allowed to change

Every Philippine business runs on a set of obligations that do not bend to software. Payroll cut-offs, BIR filings, DOLE-mandated records, SSS, PhilHealth and Pag-IBIG remittances, 13th-month pay — these have to come out right regardless of how elegant the interface is. So make them the first thing you test, not the last.

Ask the vendor to demonstrate one of those processes end to end using a sample of your own data, not their prepared dataset. A demo built on clean, invented records hides exactly the edge cases that will hurt you: the employee with mid-year movement, the branch with a different schedule, the supplier whose invoices never arrive in the same format twice.

Then ask a follow-up that separates serious vendors from optimistic ones: what happens when a government agency revises its schedule or reporting format? Who updates the system, how quickly, and is that included in what you are paying, or is it billed as a change?

Define scope in writing, then ask what falls outside it

Scope creep is the most common way an ERP project goes over budget, and it usually starts innocently. Someone in accounting mentions "we also need to track this," a manager asks for one extra report, and three months later the timeline has doubled while nobody remembers agreeing to any of it.

The protection is boring and effective: get scope written as a list of processes, not a list of modules. "Purchasing" is not a scope statement. "Purchase request, approval by department head, purchase order, three-way matching against receipt and invoice" is. Written that way, both sides can tell when something new has been added.

Then ask the uncomfortable question directly. What is explicitly excluded from this proposal? How is a change request priced, who approves it, and how does it affect the go-live date? A vendor who has run real implementations will have a clear answer. One who says "we'll handle whatever you need" is either inexperienced or planning to bill you later.

Treat data migration as its own project

Data migration is where optimistic timelines go to die. Your existing records live in spreadsheets, in an old system nobody fully understands, and in the head of the person who has been doing the job for eleven years. Moving all of that into a structured system is not a weekend task, and it is rarely the vendor's job alone.

Decide early what actually needs to move. Master data — customers, suppliers, employees, items, the chart of accounts — has to be complete and clean, because everything downstream depends on it. Opening balances have to be reconciled and signed off by someone who can defend the numbers. Historical transactions are usually the item to argue about: keeping five years of detail sounds prudent, but it multiplies the cleanup effort, and an archived copy of the old system often serves the same purpose for far less money.

Ask for a trial migration well before go-live, with a defined checkpoint where your own accountant confirms the balances tie out.

Ask how access is controlled once the system is live

An ERP concentrates information that used to be scattered across separate files and separate people. That is the benefit, and it is also the risk. On day one everyone can suddenly see payroll figures, margins and supplier pricing unless someone has deliberately decided otherwise.

ERPat handles this through its Security module, which covers accounts, sessions, roles and granular access control across every module. What matters in an evaluation is not that a vendor has such a feature — most do — but whether you can see it working. Ask them to open the role configuration screen live and build a role in front of you: a warehouse clerk who can receive stock but cannot see cost, for example.

Bring your segregation-of-duties requirements to that session. The person who creates a supplier should not be the person who approves payment to it. If the system cannot express that separation cleanly, you will end up enforcing it with memos, which auditors do not accept and busy staff do not follow.

Ask how the system handles more than one company

A surprising number of Philippine SMEs are not one company. There is the trading entity, the services entity registered a few years later, sometimes a separate branch with its own books. If that describes you — or might within three years — raise it during evaluation, not after implementation has started.

ERPat's Tenancy module supports multi-tenant management, running multiple separate tenant instances from a single deployment. The practical question to ask any vendor is where the boundary sits: are the books genuinely separate, can a user be given access to one entity and not another, and what does adding a second entity cost once the first is live?

Retrofitting a second company onto a system that assumed one is among the more expensive corrections in this field. It is a cheap question to ask now and a costly one to skip.

Ask what "integrated" actually means on the finance side

Every vendor describes their product as integrated. The word is worth nothing until you trace one transaction through it yourself. Take a purchase from request to payment to the general ledger, and watch whether anyone has to re-encode the same figures at a handover point. If they do, you are buying separate systems that share a login screen.

ERPat's Finance module covers accounts, expenses, payments, loans and reconciliation, with automated tax calculations and dynamic reports. During a demo, ask to see reconciliation performed on records created earlier in the same session rather than on a pre-built example. That single request tends to reveal more than an hour of slides.

None of these questions require technical expertise — only the willingness to keep asking until the answers are specific. A vendor who welcomes that scrutiny is usually one worth working with, and the hour you spend on it now is the cheapest part of the entire project.