ERP Business Analyst, Philippines

Turning BIR expectations into system requirements

A Philippine ERP has to satisfy rules that go deeper than a tax code table. Invoices carry required content and controlled serial numbers, books of accounts must be maintained in a form the BIR accepts, and a computerized accounting system generally needs registration or acceptance before it takes over from existing books. The precise steps change from time to time, so your accountant or tax advisor confirms what applies.

In the BRD I express these rules as concrete, testable statements, for example:

• Each branch issues invoices from its own controlled series, and numbers cannot be skipped or reused.
• A cancelled invoice remains in the system, marked as cancelled, with the user and reason recorded.
• Changes to posted transactions leave an audit trail showing who changed what and when.
• The system produces the books and reports your accountant lists, in the layout they need.
• The vendor can supply the system documentation the registration process asks for.

Each statement has an owner and an acceptance test. I also flag the timing dependency: registration evidence usually needs a configured, tested system, so the BRD records it as a milestone before go-live rather than a task afterward. This approach follows my ERP requirements gathering method.

Withholding taxes in the purchase and sales cycle

Withholding can take considerable manual effort in a Philippine finance team, and generic ERP requirement templates may not mention it at all. When your company pays certain suppliers, tax may need to be withheld and a certificate issued. When customers pay you, they may withhold in turn and send certificates that finance has to collect and match. Which payments are covered and at what treatment is decided by your accountant; the system has to apply their decisions consistently.

I document the requirements in both directions:

• Payables: how a supplier's withholding treatment is stored, how it is calculated on bills and payments, how certificates are produced, and how the withheld amounts feed the returns and summaries your accountant prepares.
• Receivables: how expected withholding is recorded on customer invoices, how certificates received are logged against the right payment, and how unmatched amounts are followed up.
• Master data: who sets and approves withholding details on supplier and customer records.

Each requirement becomes a scenario in testing, using real supplier bills and customer remittances. Platforms can differ in how they handle this area, so it deserves real weight in the fit-gap scoring explained on my ERP gap analysis page.

Readiness for the e-invoicing direction

The BIR has been shifting invoicing and sales reporting onto electronic channels, beginning with selected groups of taxpayers. Coverage, technical methods and timing are still evolving, and whether your company is affected is a question for your tax advisor. A business analyst can still make the BRD resilient, so that a future obligation does not force a second project.

I record a small set of readiness requirements that make sense regardless of timing:

• Every invoice originates in the ERP from structured order or contract data, never from a word processor or a separate billing spreadsheet.
• Customer identifiers, registered names and addresses are mandatory and validated when a customer is created.
• Credit and debit memos always reference the invoice they adjust.
• The platform offers an integration route, natively or through a provider, that could carry invoice data to an external system.

During vendor demonstrations, I ask each one to explain how it expects to support Philippine e-invoicing and what relies on partners or future releases, and I record the answers verbatim in the fit-gap notes. That gives management a documented basis for the decision instead of a verbal assurance. My BRD consulting page shows how such forward-looking requirements are marked in the document.

Stakeholders in BPO, shared service and subsidiary settings

Philippine operations that serve a foreign parent or overseas clients bring more voices into requirements. A global process owner may define how procure to pay should work across the group. A regional controller wants reporting in the parent's chart of accounts and calendar. Local finance needs BIR-compliant books in PHP. Operations leaders want margin by client, program or site. Each perspective is valid, and each can quietly override the others if nobody records them.

I interview each group separately, then bring the conflicts into one review. The BRD marks every requirement with its source, so it is clear whether a need comes from the parent's policy, local compliance or operational management. Where these clash, such as a group approval workflow that ignores local invoice rules, the document states the conflict and the agreed resolution.

For service operations, I map how revenue is earned and billed, from contracts and rate cards through usage capture to USD invoicing, and how payroll, facilities and technology costs are allocated. Companies registered in economic zones may also have incentive-related reporting that your advisor confirms, which I list as its own requirement group. My ERP business analysis service describes how the stakeholder map is built and kept up to date.

Branch processes, local-language artifacts and acceptance testing

Distributors and retailers with branches across several islands need requirements for stock transfers in transit, branch-level invoice series, cash handling and consolidated reporting at head office. I map how goods and documents move between the main warehouse and branches, including what happens when shipments are delayed or partially received, and which reports branch managers and head office each depend on. See my ERP process mapping page for the method.

Project documents are written in English. Where branch or warehouse staff learn best in Filipino or another local language, quick reference guides and training notes are adapted by your trainers or a local partner. I list each such artifact in the BRD with a named reviewer, so it is checked by someone fluent before go-live.

Fit-gap scoring rates every requirement by how the platform meets it: as delivered, by setup, through an extension or provider, or only through development. My Philippine pages for ERPNext, Zoho, Dynamics 365 and Odoo cover the local checks. Acceptance scripts then test a branch sale, a supplier payment with withholding, a cancelled invoice and a USD client bill against PHP books. For advisory help beyond analysis, see freelance ERP consultant in the Philippines or the Philippines ERP consultant page.