Added service recorded
Additional workshop · 4 hours
- Approval
- Pending
- Billing
- On hold
The project manager records what has been added to the original scope.
ERP for service businesses
connect projects and billing
Custom ERP workflows for project scope, recorded effort and financial handovers.
When an ERP fits your project business
An extra task has been agreed, the work is done, but billing is waiting for approval. SYNQ develops custom ERP workflows for service businesses that want to connect project scope, recorded effort and financial handovers. We start with the process where your team is missing information today.
Consultancies, IT service providers, agencies and other project businesses deliver work under different commercial arrangements. One project has a fixed fee, another is billed by time, while recurring services continue alongside them. The important question is whether the system preserves those differences through to approval.
Consider a custom approach when the same questions remain unresolved: Is this task included in the order? Who approved the change? Has the recorded time been checked? Which items have already been billed? If the answers sit across spreadsheets and messages, a shared process review is a useful starting point.
Team size alone is not a selection criterion. A small company with a few clear workflows may be well served by standard software. A larger business does not automatically need custom development. Our custom ERP software page explains the broader approach; this page focuses on decisions specific to project work.
Every record keeps its history.
From an additional workshop to billing handover: project context, review and decisions stay with the record.
Work assigned to the project
Additional workshop · 4 hours · Project Atlas
- Approval
- Requested
- Billing
- On hold
Work, project and owner remain connected.
Service approved
Additional workshop · 4 hours · checked
- Approval
- Approved
- Billing
- Prepared
The agreed approval is recorded and visible to billing.
Line item handed over
Additional workshop · 4 hours · checked
- Approval
- Approved
- Billing
- Transferred
The line item retains its project context. No retyping is needed in this example.
1 / 4
Connect additional work to the project order
An ERP for service businesses needs an explicit relationship between the agreed service and subsequent changes. A new task should not silently overwrite the original scope. It needs a reason, an owner and a visible decision status.
Illustrative example: A consulting team is asked to produce documentation in addition to an agreed workshop. The project manager records the request and assigns the expected effort. Only after the agreed confirmation does it become an approved service item. Billing then reflects the scope that was actually agreed.
- Additional workAdd documentation · scope pending
- Review effortProject manager assigns the work and its owner
- Record the decisionConfirmation references the proposal version
- Prepare billingApproved item with supporting delivery record
Rejection, clarification and later corrections belong in the same process. Each case should retain the applicable version and the person responsible for the decision. This example describes a possible scope; it is not a screen from an existing SYNQ standard product.
Shared data, different responsibilities
Project managers, delivery teams and finance need different views of the same work. The team records a service. The project manager checks its allocation and scope. Finance checks whether the agreed conditions for billing have been met.
A project record can connect the customer, order, service items, effort, supporting records and approvals. Permissions should follow these responsibilities: Who can correct time, change scope or reopen an approved item? A status label alone does not answer those questions.
- Delivery team
- Records work and supporting evidence. Sees assigned tasks.
- Project manager
- Reviews scope and changes. Decides on internal approval.
- Finance
- Checks billing status and handover. Receives approved items.
For project cost review, planned and actual figures need the same basis. Separate the original agreement, approved additions and effort actually incurred. Otherwise an apparent budget variance may simply reflect additional work that was never added to the plan. Whether internal cost rates, subcontractors or travel expenses are included is a business decision.
Distinguish fixed fees, time billing and recurring services
The billing model determines which information must be available before handover. Time recording can support internal cost review on a fixed-fee project without automatically determining the invoice amount.
| Model | What the workflow should establish | Exception to test |
|---|---|---|
| Fixed fee | Agreed scope, milestones and approval conditions | Additional work changes scope after the order is placed |
| Time based | Service type, time unit, rate and review rule | Time was allocated incorrectly or corrected later |
| Recurring service | Period, included work and change rule | A service begins, pauses or ends partway through a billing period |
| Mixed order | Each item belongs to its relevant model | Additional work is billed separately from the base order |
This table is a planning aid. Tax, contractual and sector requirements need a separate review for the actual use case and jurisdiction. An accounting application can continue the process prepared by the ERP; a complete accounting system is not automatically included in every project.
Recorded does not mean approved.
Approve the four additional hours. They move into the billable total through an explicit decision.
Ready for billing
Still pending
Standard software, configuration or custom development
Give each candidate solution the same example order. Ask for additional work to be recorded, an approval to be withdrawn and a corrected delivery record to be handed over again. This reveals whether an existing product is sufficient, whether configuration or an extension would work, or whether a custom application is justified.
For a smaller service business, a properly configured existing system may be the right choice. A mid-sized company with several departments also needs to check shared master data, separate permissions and approval responsibilities. Field service, material consumption or sector-specific records introduce further requirements that need individual assessment.
Record the decisive scenarios in an ERP requirements specification. This lets you compare the same business outcome instead of choosing the longest feature list.
Start with a bounded project workflow
For an initial usable scope, we identify one connected workflow, such as additional work through to billing handover. You provide an anonymised sample order, typical changes and the applications involved. A business owner resolves open rules; technical access and data exports need to be assessed.
These inputs help define the data model, roles, interfaces and acceptance criteria. A prototype illustrates the intended user flow. Before operational use, the project needs tests covering relevant exceptions, data migration, training and an agreement on responsibility for defects and future changes.
Existing CRM, time or accounting systems do not all have to be replaced. For each data type, the project establishes which application is authoritative and how changes are reported back. AI may prepare information for review where the use case supports it; business rules and responsibilities must also be clear without AI.
Plan scope and operation together
Effort depends on the number of workflows, existing data quality, interfaces and the depth of approval rules. Operation, support and later changes also need to be included. Our overview of ERP costs helps organise these items into a comparable budget.
Start with one concrete order: What service do you sell, where does its scope change, and what information is missing before billing today? These details provide a basis for defining a useful first project scope.
Your workflow is the starting point.
Bring a real workflow and your open questions. They help define a useful first scope.
Discuss your project