For a fixed fee services contract, I track the work in Dynamics 365 Sales against the scope in the agreement, show the client their own progress on a signed in portal page, and raise each phase's invoice in QuickBooks from the CRM once the phase is complete. The three systems read from one record of the work, so the client's page, the CRM, and the invoice agree on what was delivered and what it cost.
- Dynamics 365Scope becomes tasksOne task per scoped item, with its phase, scoped hours and target date
- Dynamics 365Work is recordedStatus and actual hours entered on each task as the work is done
- Client portalClient pagePlanned against actual hours, generated from the CRM
- Dynamics 365Phase is completeEvery task in the phase closed; an order is raised for the phase fee
- Dynamics 365Order is switched to invoiceA Power Automate flow calls a connector that can only create invoices
- QuickBooksInvoice is created, unsentCustomer, fee, GST and bank payment set; the number is written back to the order
- QuickBooksReviewed and sentNumber and preview checked, then sent; the client pays by bank transfer
The agreement's scope becomes the task list
Each item in the agreement's scope of work becomes a Client Work task in the CRM. The task carries the client and phase, the hours the agreement estimated for that item, a plain description of the work taken from the agreement, and anything the client has to supply before it can start. The wording comes from the agreement the client signed, and I approve each task before it is created.
Target dates are set from the start date at a planned 40 hours a week, skipping statutory holidays, and a phase's target is the latest due date among its tasks. A phase that starts only when the client gives written notice to proceed has its tasks set to Deferred, so the plan shows the whole engagement without implying the later phases are committed.
Hours are recorded against the estimate as the work is done
Each task's status changes as the work moves, and its actual hours are entered when it is completed. Because the fee is fixed per phase, a variance is shown rather than billed: when a task runs over its estimate, its description states how many hours were added, the finding that caused them, and that they fall within that phase's fee.
This places the explanation at the task where the hours were spent. A client reading the page sees an overrun and its cause while the phase is still open, rather than meeting it for the first time on an invoice.
The client sees the same record on the portal
Each client has one page on the Authgnosis client portal, opened by signing in with a Microsoft account that holds that client's role. No page names another client. The page shows each phase's completion, planned against actual hours for every phase and task, what each task delivered, and what the client still needs to supply. Phase deliverables are downloaded from the same page, and each download is recorded in the CRM against the person who downloaded it.
The page is generated from the CRM rather than edited by hand, and I review it before it is published. A status change in the CRM therefore reaches the client on the next build, in the same words, and the page cannot report progress the CRM does not hold.
Phase completion raises the invoice from the CRM
When every task in a phase is complete, an order for that phase's fee is created in the CRM against the client's account, which carries its QuickBooks customer ID. Switching the order to Raise QuickBooks invoice starts a Power Automate flow. The flow calls a custom connector that can only create invoices: it cannot send, change, or delete one. A key written into each invoice stops the same order from producing a second invoice if the flow runs twice.
The invoice is created unsent, with the customer, the phase fee, GST, and online payment by bank transfer already set, and its QuickBooks number is written back to the order. I check the number and the preview in QuickBooks and send it from there, and the client pays it from the invoice email.
Features, advantages, and benefits
Each feature of the integration does one job in the contract's life. The table below sets out what each one is, what it does that a manual process does not, and what the client gets from it.
| Feature | Advantage | Benefit |
|---|---|---|
| Tasks created from the agreement's scope, each with its phase, scoped hours, and target date | The task list matches the agreement item for item | The client can check any task against the contract, and work outside the scope has to be added on the record before it is done |
| Actual hours recorded on each task against its estimate | A variance shows at the task where it occurred, with its cause | The client sees an overrun and the reason for it while the phase is still open, before the phase invoice is raised |
| A client portal page generated from the CRM, opened only with that client's sign in | The client reads the same record I work from, and only their own | Progress can be checked at any time, without a separate status report to request or prepare |
| Phase deliverables downloaded from the portal, each download recorded in the CRM | There is a record of who received each deliverable and when | Handover is documented without a follow-up message to confirm receipt |
| The invoice raised from the CRM order by a flow that can only create invoices | Customer, fee, and tax come from the order, and one order cannot produce two invoices | The invoice matches the agreement's phase fee with nothing keyed twice, and a fault in the flow cannot send or change an invoice |
| The invoice created unsent, with online payment by bank transfer | Every invoice is reviewed before the client receives it | The client receives a checked invoice and can pay it directly from the email |
What the integration changes
Nothing is keyed twice. The phase fee on the invoice comes from the order, the order from the agreement's phase, and the hours on the client's page from the same tasks I record my time on. The client can compare the hours with the estimate throughout the phase, so by the time the invoice arrives, the hours behind it have been on the client's page for as long as the phase ran.
The one step kept manual is the send. Creating the invoice is automated because its contents are fully determined by the agreement and the order; sending it is a judgment about whether the phase is finished from the client's side, and I make that call myself.
The design works with most websites, CRMs, and accounting systems
Nothing in the design depends on these three products. It depends on three capabilities: a CRM that holds tasks with a phase, estimated hours, and actual hours, and exposes them through an API; an accounting system whose API can create an invoice without sending it; and a website that can serve a page only to a signed in client. Most current platforms meet them. HubSpot, Salesforce, and Zoho CRM can hold the tasks; Xero and FreshBooks, for example, can create an invoice as a draft; and a client page can sit behind sign in on most content management systems, or on a small separate site, as it does here.
Adapting the design to another set of systems is therefore mainly a matter of mapping the agreement's scope to that CRM's task records, matching the invoice fields to that accounting system, and deciding where the human review sits before anything reaches the client.
See the whole flow on a sample engagement
The client portal, the CRM records, and the invoice flow working together on a fictional client, from the agreement's scope to the sent invoice.