How to Implement NetSuite for Services Companies: Steps and AI Skill

A services company sells hours. Not stock, not licenses, hours delivered by people whose time is simultaneously the cost of sale, the basis of the invoice, and the trigger for revenue. That collapses three separate accounting questions into one transaction, and it is why services implementations fail in a way that distribution and software implementations do not. This guide sets out the consultant-level steps, the configuration decisions that carry the most downstream weight, and a machine-readable skill file you can hand to an AI assistant to run the same method.

The Short Answer

Short answer: Implement NetSuite for a services company in seven phases:

Discovery and Scoping → Solution Design → System Configuration → Data Migration → User Acceptance Testing → End-User Training → Go-Live and Hypercare

What makes the services version distinct is that the primary transaction is the timesheet line, not the sales order. A single approved time entry has to cost the project, feed the invoice, drive revenue recognition, and count toward utilization. All four depend on rates that must already exist on the right records before anyone enters time. Configure the rate architecture late and the system produces projects with revenue and no cost, which looks like extraordinary margin until someone checks.

The three process areas a services implementation genuinely turns on are Project Management, Resource Management, and Revenue Management, sitting on top of Master Data Management. Inventory, warehousing, and production are out of scope, and Order to Cash is present but subordinate, because billing derives from project charges rather than from orders.

Methodology note. The sequence below follows the seven-phase implementation methodology Azdan applies across its NetSuite delivery work in the UAE, Saudi Arabia, and Egypt, adapted here to the professional services process model. Where a point reflects delivery experience rather than measured data, it is labeled as a recommendation.

What Makes a Services Implementation Different

In a distribution business, value moves when goods move. In a software business, value is a contract term running on a schedule. In a services business, value is created by a person, on a day, against a task, and it stops existing if nobody records it.

That last clause is the whole problem. Inventory sitting in a warehouse is still there tomorrow whether or not anyone updates the system. An hour worked on Tuesday and never entered is gone. It cannot be billed, it never costs the project, and it never appears in utilization. No other ERP vertical has a primary transaction that evaporates when adoption slips.

This produces a scoping profile that looks very different from a standard mid-market ERP project:

The reduced footprint is not a smaller project. Services implementations concentrate their complexity in project accounting and resource management, and the scoping conversation should be shaped accordingly.

The Employee Record Is the Control Point

This is the single most consequential thing to understand before configuration begins, and it is where the services model diverges most sharply from the software one, where the item record plays this role.

In NetSuite, the labor cost of project work is calculated from the hourly cost held on the employee record, multiplied by the hours worked, and it can be overridden on the project task assignment where a specific engagement needs it. The employee record also carries the target utilization percentage, which NetSuite multiplies by the employee's work schedule to produce the available hours figure that every utilization report is measured against.

The consequence is unforgiving and worth stating plainly: if labor cost is not populated on the employee record before time is entered, that time has no cost. It is not flagged and it does not fail. The project simply reports revenue against zero labor cost, and the margin looks excellent. Recommendation: treat employee cost rates as a Phase 2 design deliverable with a named owner, and make their existence a precondition of opening time entry, not a data task to catch up on later.

Two Rate Systems, Not One

The second thing teams conflate. Cost rates and bill rates are separate architectures living on separate records, and they answer different questions.

For simple requirements, rates on the service item are enough. Where pricing varies by seniority, by role, or by client, rate cards and billing classes provide the granularity, and rate cards support effective dating so an annual rate change is a new version rather than a destructive edit. Firms that renegotiate rates each January should be on rate cards from day one, because retrofitting them after a year of history is considerably harder than starting with them.

The Implementation Value Chain for Services Companies

A Gantt chart shows when work happens. A value chain shows where value is created and which supporting disciplines have to run continuously for the primary activities to hold together. For an ERP implementation the second view is more useful, because failures rarely come from a phase running late. They come from a support activity that was treated as a phase and then stopped.

Primary activities, in sequence:

Support activities, running across every phase:

• Program governance and change control
• Rate card and master data management
• Revenue and margin assurance
• Time and expense adoption
• Localization, payroll, and compliance

The margin: every hour costed, every project's margin visible while it can still be influenced, and every invoice out on time.

Time and expense adoption earns its place on that list in a way it would not in any other vertical. In a distribution implementation, adoption failure produces friction. In a services implementation it produces missing data, and missing data cannot be recovered by trying harder next month. That is why it is a discipline running from discovery through hypercare rather than a training session in Phase 6.

The Seven Steps

Step 1: Discovery and Scoping

The objective is a documented engagement model, a rate policy, an entity map, and a defensible scope boundary.

Work through:

• Engagement types. Time and materials, fixed fee against milestones, fixed fee recognized on progress, retainer, capped time and materials, and pro bono or internal. Each maps to a different combination of billing rule and revenue rule, so the list determines the configuration, not the other way around.
• Rate policy. Whether bill rates vary by person, by role, by client, or by contract, and how often they change. This decides service item pricing versus rate cards and billing classes, which is a design decision with a real cost to reverse.
• Cost policy. How labor cost per person is derived. In the GCC this is rarely just salary, and getting it wrong is covered in its own section below.
• Legal entity structure. Subsidiaries, countries, functional currencies, and whether consolidated reporting by practice or office is required.
• Who enters time, and on what cadence. Employees, contractors, and subcontractors have different routes into the system and different approval paths. Weekly submission with a lock period is the workable default.
• Subcontractors and sub-consultants. Whether third-party delivery cost has to land on the project P&L. For engineering and IT services firms it almost always does, and it changes the Procure to Pay scope.
• The metrics the business runs on. Utilization, realization, project margin, backlog, and days sales outstanding. Naming them in discovery determines what has to be captured, because a metric nobody designed for is a metric nobody can report.

Exit gate: a signed scope document listing every engagement type with its intended billing and revenue treatment, the rate policy, the entity structure, and an explicit out-of-scope list.

Step 2: Solution Design

The output is a design a configurator can build from without making commercial or accounting decisions.

Chart of accounts and segmentation. Carry reporting dimensions on segments rather than in account numbers. Services firms typically need department for practice or discipline, class or a custom segment for service line, and location for office. Get this right and practice-level profitability is a report. Get it wrong and it is a rebuild.

Project and task structure. Project tasks should be treated as phases, not as a work breakdown structure copied from a delivery plan. Limit them to what reporting and billing actually require, because every additional task is a decision a consultant has to make correctly at the moment of entering time. Recommendation: if a task does not change how something is billed or reported, it does not belong in NetSuite.

Rate architecture. Cost rates per person or per job function on the employee record, bill rates on service items or rate cards, and billing classes where seniority-based pricing applies. Define the default and the exception path for both.

Billing rules and charge rules. Charge-based billing is the engine to design against, because it handles labor, expense, and fixed fee in one model rather than requiring separate mechanisms. Charges progress from forecast to actual, and actual charges can sit as ready, on hold, or non-billable, which gives project managers a review step before anything reaches an invoice.

Project revenue rules. This table is the core artifact of a services implementation. It reflects NetSuite's leading-practice configuration patterns for project revenue treatment:

Two decisions follow from that table and both are easy to skip.

First, the percent complete denominator. Project completion can be calculated from planned time only, or from planned plus actual hours where actual has overrun the plan. The two produce materially different revenue in any month where a project is running over, so the controller picks it, not the configurator.

Second, calculated versus overridden percent complete. The native calculation is approved time entries divided by estimated hours on project tasks. Finance can instead enter percentage figures manually per accounting period, which requires enabling the percent complete override for revenue forecasting. Manual override is legitimate and common on engineering and construction-adjacent work, but it moves revenue recognition from a system-derived number to a judgment, which the audit position needs to reflect.

Whether revenue runs from the project or the sales order. Firms that do not use sales orders should use project revenue rules configured on the project. Firms that do use sales orders, or that sell goods alongside services, should drive recognition from the sales order with rules on item records. Mixing both without deciding is a common source of duplicate or missing revenue.

Utilization design. Set target utilization on the employee record so available hours are correct in every utilization report. Decide whether generic resources will be used to represent unfilled roles on project templates, which turns a staffing gap into a reportable number rather than a conversation.

Exit gate: a functional design with the engagement type matrix and rate architecture signed off by the finance owner and the delivery lead, not only by the project sponsor.

Step 3: System Configuration

Build against the design, in this order:

1. Company setup, subsidiaries, currencies, consolidated exchange rates, and accounting periods
2. Chart of accounts and segments
3. Roles and permissions, starting from bundled role definitions and restricting from there
4. Employee records with cost rates and target utilization populated
5. Service items, rate cards, and billing classes
6. Customers, projects, and project templates
7. Billing rules, charge rules, and project revenue rules
8. Time and expense preferences: entry thresholds, lock periods, approval routing
9. Tax configuration, e-invoicing templates, and bank payment formats per country
10. Saved searches, KPIs, dashboards, and utilization and profitability reporting

Step 4 is deliberately ahead of step 6. Employees must be complete before projects exist to book time against.

Configure time approval routing explicitly. Setting the project time approver routes client-facing time to the project manager, while internal project time goes to the employee's supervisor. Firms that leave this at default discover in week one that one person is approving every timesheet in the company.

Recommendation: freeze configuration before UAT opens. Configuration changes during testing invalidate test results.

Step 4: Data Migration

Services firms carry a migration profile that trips teams expecting a standard finance migration.

Work in progress deserves its own workstream. Every live engagement at cutover has time already delivered, some of it billed, some of it not, and revenue recognized to a point that may not match either. Migrating that state accurately, then proving that migrated WIP and unbilled revenue tie to the legacy balance sheet, is the migration's acceptance test. Recommendation: run that reconciliation twice, once in a dress rehearsal and once with final data.

A decision that belongs here rather than later: whether to migrate historical time entries at all. Most firms should not. The transactions are numerous, the reporting value decays quickly, and bringing them across drags historical rate structures into a system designed around new ones. Migrate open project state and balances, and keep the legacy system readable for history.

Step 5: User Acceptance Testing

Write test scripts from the engagement model, not from a generic ERP script library. For a services firm, the tests that matter are:

• A time and materials engagement from timesheet entry through approval, charge generation, invoice, and recognized revenue
• A fixed fee engagement recognized on milestones, with a milestone completed and revenue posting correctly
• A fixed fee engagement recognized on percent complete, tested in a period where actual hours exceed the plan, so the denominator decision is proven rather than assumed
• A retainer drawdown across two periods, including a period where the retainer is not fully consumed
• A subcontractor cost landing on the project P&L and appearing in project margin
• An expense claim from submission through supervisory and accounting approval, rebilled to the client
• A scope reduction or claw back handled through a return authorization merged with the revenue arrangement rather than a standalone credit memo
• A full month-end close: charge generation, revenue recognition, WIP and unbilled reconciliation, and utilization reporting for the period
• A project closeout, including the sequence below

That close test is the one most often skipped for time. It should be the gate, because month-end is where a services implementation either works or does not.

Exit gate: documented sign-off from the finance owner and the delivery lead, with every high-severity defect closed and retested rather than deferred to hypercare.

Step 6: End-User Training

Services implementations have an adoption problem that other verticals do not, because the most important transaction in the system is entered by the people who care least about the system. A consultant bills clients, not timesheets. Training has to make the case, not just demonstrate the screens.

Train by role: delivery consultants on time and expense entry, project managers on allocation, charge review, and approval, finance on billing runs, revenue recognition, and close, and administrators on configuration.

Recommendation: pair training with the mechanics that make timesheet discipline hold. Lock periods with a short grace window, minimum and maximum hour thresholds per day and per week, and approval routing that puts a named person in the path. Recommendation is deliberate here: these are guardrails that work in practice, not measured findings. The point is that timesheet compliance is a design feature, not a management exhortation.

Step 7: Go-Live and Hypercare

Cut over in a low-activity window aligned to a period boundary. Rehearse the cutover with a defined rollback decision point and a named person authorized to call it.

The first close after go-live is the real go-live. Support the finance team through it directly: generating charges, running the billing operations center, posting revenue, reconciling WIP and unbilled, and producing the first utilization and project margin reporting from the new system.

Build project closeout into hypercare as a repeatable sequence rather than an ad hoc cleanup. Enter all remaining costs including time, expense, and payables. Run final billing. Run revenue recognition. Disable time entry and expenses on the project to prevent further charging. Then set the project to closed and inactive so it stops appearing on new transactions. Skipping the disable step is how a closed project acquires a stray time entry three months later and reopens a period that was already reported.

Recommendation: keep the legacy system readable, not writable, for at least one full quarter.

Costing Labor Correctly in the GCC

This is where regional services firms most often carry an error that no configuration review would catch, because the number in the system is populated and looks reasonable.

A labor cost rate is meant to represent what an hour of a person's time costs the business. In markets where compensation is essentially salary plus statutory contributions, dividing annual salary by productive hours gets close. In the GCC it does not, because several material costs accrue outside salary:

• End-of-service gratuity. It accrues across an employee's tenure on a statutory formula that varies by country and by reason for leaving. It is a balance sheet provision maintained continuously, not a payroll event at termination. A cost rate that excludes it understates the cost of every hour that person delivers.
• Air ticket entitlement. Annual or biennial repatriation flights for expatriate staff and often dependents. It accrues like a benefit, carries eligibility rules, and is a genuine cost line.
• Statutory contributions. GOSI in Saudi Arabia, social insurance in Egypt, and the relevant schemes elsewhere.
• Housing, transport, and other allowances where the employment contract carries them.

The practical implication for an implementation: the blended cost rate loaded onto employee records should be built from fully loaded cost, and the finance owner should be able to show how it was derived. Recommendation: rebuild the rates annually rather than treating them as static reference data, because tenure-driven accruals move.

Two further regional points that shape a services build. Payroll must reconcile to project labor cost, which means deciding early whether time posts to the general ledger or whether payroll is journaled monthly with approved time entries treated as project cost for profitability reporting. Most services firms choose the latter, which requires the project profitability configuration to include approved time as actual cost. And WPS file generation in the UAE and Saudi Arabia is a payroll output the implementation has to produce correctly from the first run, not a later enhancement.

E-invoicing under ZATCA and the UAE Federal Tax Authority applies to services firms exactly as it does to everyone else. Because the requirements are regime-level rather than industry-level, they are covered in the companion posts linked at the end rather than repeated here.

What Breaks: Seven Recurring Risks

These are patterns that recur across services implementations. They are drawn from delivery experience and offered as recommendations rather than as measured findings.

1. Cost rates missing at the point of first time entry. The defining failure of this vertical. Time posts with no cost, margin reports look excellent, and the correction is a retrospective rebuild across every affected project.
2. Cost rates that ignore gratuity and allowances. Populated, plausible, and understated. Every project margin in the business is wrong by roughly the same percentage, which makes it hard to spot by comparison.
3. Timesheet adoption treated as training. The most important transaction in the system depends on people who get no personal benefit from entering it. Guardrails belong in the configuration.
4. Task structures copied from delivery plans. Fifty tasks per project means fifty chances to book time to the wrong one. Tasks should exist for billing and reporting, not for project management theater.
5. The percent complete denominator left at default. Nobody decides it, and revenue on overrunning projects behaves in a way finance did not intend and cannot explain.
6. Subcontractor cost that never reaches the project. It posts to the P&L, the project margin looks healthy, and the engagement is quietly unprofitable.
7. WIP under-scoped in migration. Effort is estimated on customer and invoice counts, and the in-flight delivery state, which is the genuinely difficult part, is not costed.

The AI Skill

The steps above are also published below as a skill file: a markdown document with structured instructions an AI assistant can load and follow. It encodes the same seven phases, the same engagement matrix, and the same exit gates, so an assistant can help draft a scope document, review a design against the gates, or generate role-based UAT scripts without the consultant restating the method each time.

Copy the block below and save it as SKILL.md inside a folder named netsuite-services-implementation.

---
name: netsuite-services-implementation
description: >
  Method for implementing Oracle NetSuite at professional services companies. Load
  this when scoping, designing, configuring, testing, or reviewing a NetSuite
  implementation for a consulting firm, IT services company, engineering or management
  consultancy, agency, or any business that bills for delivered hours. Also use when
  writing a statement of work, a functional design document, a project revenue
  recognition design, a rate card architecture, a data migration plan, or UAT scripts
  for such a project. The expensive failure here is opening time entry before labor
  cost rates exist on employee records, which produces projects with revenue and no
  cost, and this skill exists to prevent that.
---

# NetSuite Implementation for Services Companies

Seven phases, each with an exit gate. Do not advance past a gate that has not been met.
Say which gate is unmet rather than proceeding.

## Scope rules

Applies to companies whose economic unit is a delivered hour: consulting, IT services,
engineering and management consultancy, agencies, and professional services groups.
Does not apply to inventory-led businesses.

Process areas in scope by default: Master Data Management, Project Management, Resource
Management, Revenue Management, Financial Management. Subordinate: Order to Cash, since
invoices derive from project charges. Standard: Procure to Pay, where subcontractor cost
must land on the project. Out of scope by default: Design to Build, Ship Central,
warehouse and inventory management.

## Hard rules

1. Labor cost rates must exist on employee records before time entry opens. Time
   entered without a cost rate has no cost, silently. Treat this as a Phase 2
   deliverable with a named owner.
2. Cost rate and bill rate are separate architectures. Never conflate them. Cost lives
   on the employee record, bill lives on the service item, rate card, or billing class.
3. In the GCC, a cost rate built from salary alone is wrong. Include end-of-service
   gratuity accrual, air ticket entitlement, statutory contributions, and contractual
   allowances.
4. Never invent a client's rate policy, engagement mix, or revenue treatment. If it is
   unknown, list it as an open question and stop.
5. Never state a regulatory threshold or deadline from memory. Verify against the
   regulator and record the check date.
6. Label anything not verified as a recommendation, not a fact.
7. Do not name or identify any client in any output.

## Phase 1: Discovery and Scoping

Collect: every engagement type in use (T&M, fixed fee by milestone, fixed fee by
progress, retainer, capped T&M, internal); rate policy and how often rates change; how
labor cost per person is derived; legal entity structure with countries and functional
currencies; who enters time and on what cadence; whether subcontractor cost must reach
the project P&L; the metrics the business runs on.

Flag as high risk: bill rates varying by person rather than role; percent-complete
engagements with no agreed denominator; subcontractor delivery with no project costing
route; any intention to open time entry before cost rates are loaded.

Exit gate: signed scope listing every engagement type with intended billing and revenue
treatment, rate policy, entity structure, and an explicit out-of-scope list.

## Phase 2: Solution Design

Produce a functional design covering:

- Chart of accounts and segments: department for practice, class or custom segment for
  service line, location for office, so practice profitability is a report not a rebuild.
- Rate architecture: cost rates per person or job function on the employee record with
  the task-assignment override path defined; bill rates on service items, rate cards, or
  billing classes. Use rate cards where rates change annually, since they carry
  effective dates.
- Project and task structure: tasks are phases for billing and reporting. If a task does
  not change how something is billed or reported, it does not belong.
- Billing rules and charge rules using charge-based billing, covering labor, expense,
  and fixed fee. Define the review step for ready, on hold, and non-billable charges.
- Utilization: target utilization on employee records, generic resources for unfilled
  roles on project templates.
- Reporting: utilization, realization, project margin, backlog, DSO.

Engagement matrix, the leading-practice starting point:

| Engagement type | Billing rule | Revenue rule | Plan created when |
|---|---|---|---|
| Time and materials | Time-based | As Charged | Billing charges created from time entries |
| Fixed fee, milestone | Fixed fee | Fixed Amount | Milestone marked completed |
| Fixed fee, progress | Fixed fee | Percent Complete | Percent complete updated |

Two decisions the controller must make, not the configurator:

- Percent complete denominator: planned time only, or planned plus actual where actual
  has overrun. These differ materially on any overrunning project.
- Calculated or overridden percent complete. Native calculation is approved time divided
  by estimated hours on tasks. Manual override per period requires enabling percent
  complete override for revenue forecasting, and moves recognition to a judgment.

Also decide whether revenue runs from the project or the sales order. Project revenue
rules where sales orders are not used; sales order recognition where they are, or where
goods are sold alongside services. Do not leave both active without deciding.

Exit gate: design signed by the finance owner and the delivery lead, not only the
project sponsor.

## Phase 3: System Configuration

Build in this order: company, subsidiaries, currencies, consolidated exchange rates,
periods; chart of accounts and segments; roles from bundled definitions, restricted;
employee records with cost rates and target utilization populated; service items, rate
cards, billing classes; customers, projects, project templates; billing rules, charge
rules, project revenue rules; time and expense preferences including entry thresholds,
lock periods, approval routing; tax, e-invoicing, bank payment formats; searches, KPIs,
dashboards, utilization and profitability reporting.

Employees are configured before projects. Projects have nothing to cost without them.

Set time approval routing explicitly: project time approver for client-facing work,
supervisor for internal. Default routing sends every timesheet to one person.

Integration credentials use a web-services-only role, never a user login.

Freeze configuration before UAT opens.

## Phase 4: Data Migration

Elements: employees with cost rates, target utilization, work schedules, approval
hierarchy, skills; customers deduplicated; service items and rate cards with effective
dates; open projects with budget, tasks, remaining scope; work in progress; open
transactions including unbilled charges and retainer advances; historical trial balance.

Work in progress is a workstream, not a data element. Acceptance test: migrated WIP and
unbilled revenue tie to the legacy balance sheet. Run the reconciliation twice, once in
dress rehearsal and once with final data.

Recommend against migrating historical time entries. High volume, fast-decaying value,
and it drags legacy rate structures into the new design. Migrate open state and balances.

## Phase 5: User Acceptance Testing

Write scripts from the engagement model. Mandatory scenarios: T&M engagement from
timesheet to recognized revenue; fixed fee on milestones with a milestone completed;
fixed fee on percent complete tested in a period where actual hours exceed plan;
retainer drawdown across two periods including partial consumption; subcontractor cost
landing on project margin; expense claim through both approval levels and rebilled;
scope claw back via return authorization merged with the revenue arrangement; full
month-end close including charge generation, revenue recognition, WIP and unbilled
reconciliation, and utilization reporting; project closeout.

The close test is the gate. Do not sign off without it.

Exit gate: finance owner and delivery lead sign-off, all high-severity defects closed
and retested.

## Phase 6: End-User Training

Role-based against real scenarios: delivery consultants on time and expense, project
managers on allocation and charge review, finance on billing runs and close,
administrators on configuration.

Adoption is the risk unique to this vertical, because the most important transaction is
entered by people who get no personal benefit from entering it. Pair training with
configuration guardrails: lock periods with a short grace window, minimum and maximum
hour thresholds, and approval routing with a named person in the path.

## Phase 7: Go-Live and Hypercare

Cut over in a low-activity window aligned to a period boundary. Rehearse cutover with a
defined rollback decision point and a named decision owner.

Support the first close directly: charge generation, billing operations center, revenue
posting, WIP and unbilled reconciliation, first utilization and margin reporting.

Project closeout sequence, repeatable: enter all remaining costs including time, expense
and payables; run final billing; run revenue recognition; disable time entry and
expenses on the project; set status to closed and the record to inactive. Skipping the
disable step lets a stray time entry reopen a reported period.

Keep the legacy system readable for at least one quarter.

## Support activities, continuous across all phases

Program governance and change control; rate card and master data management; revenue and
margin assurance; time and expense adoption; localization, payroll, and compliance.
These are disciplines, not milestones. Time and expense adoption in particular runs from
discovery through hypercare, because missing time cannot be recovered later.

## Failure patterns to check for

Cost rates missing at first time entry; cost rates excluding gratuity and allowances;
timesheet adoption treated as training; task structures copied from delivery plans; the
percent complete denominator left at default; subcontractor cost never reaching the
project; WIP under-scoped in migration.

## Output formats

- Scope document: entity map, engagement type table with billing and revenue treatment,
  rate policy, out-of-scope list, open questions.
- Design document: engagement matrix populated for this client, rate architecture, task
  structure, utilization and reporting design.
- Migration plan: element table with volumes, source, complexity, and the WIP tie-out
  procedure.
- UAT pack: scenario scripts by role, with the close scenario marked as the gate.

Always end with an explicit list of open questions and unverified assumptions.

How to Use It

Save the block as SKILL.md in a folder named netsuite-services-implementation, then place that folder wherever your assistant loads skills from. Load it at the start of a services project and it will hold the same gates a consultant would. It is a starting position, not a substitute for a qualified consultant reviewing the rate and revenue design.

Recommendation

If you are scoping a NetSuite implementation for a services company, answer two questions before anything else is estimated. First, list every engagement type the firm sells and the revenue treatment each needs. Second, establish how a fully loaded labor cost per person will be derived, and name who owns it. Those two answers shape the configuration, the effort, and the reliability of every margin number the system will ever produce, and both are cheap to answer in week one and expensive to answer in month four.

Then add a third that costs nothing and prevents the most common failure in this vertical: confirm that cost rates will be loaded onto employee records before time entry is opened to anyone.

Sources

• Oracle NetSuite, Professional Services Automation
• Oracle NetSuite, revenue recognition and revenue management
• IFRS Foundation, IFRS 15 Revenue from Contracts with Customers

Regional payroll and compliance details were checked in August 2026. Statutory formulas and thresholds change, so confirm against the relevant authority before acting on them.

Related Azdan Resources

• How to Implement NetSuite for Software Companies
• NetSuite ERP for Professional Services
• NetSuite ERP for Management Consulting
• NetSuite ERP for Engineering Consulting
• NetSuite Project Costing
• Oracle NetSuite Implementation

Published by Azdan, an Oracle NetSuite Solution Provider operating across the UAE, Saudi Arabia, and Egypt. Guidance in this article reflects Azdan's NetSuite implementation methodology applied to the professional services process model. Regional content checked August 2026.