--- title: How to run a consultancy on one system: from proposal to paid invoice canonical: https://getcyril.com/blog/run-a-consultancy-on-one-system/ published: 2026-10-12 author: Cyril team language: en --- # How to run a consultancy on one system: from proposal to paid invoice Most consultancies do not choose their software stack. It accumulates. A CRM arrives when the partners stop remembering every conversation. Proposals live in a word processor because that is where they were always written. Someone adds an e-signature tool, then a project board, then a timesheet app because the project board's time tracking was an afterthought. Invoicing sits in the accounting package, and the client asks for updates by email because there is nowhere else to look. Each choice was sensible. Together they mean that a single engagement, from first conversation to paid invoice, is retyped four or five times by people who were not in the room when it was agreed. This post is about what it takes to run that whole lifecycle in one system: what the system has to do, how to test a vendor's claim that theirs does it, and where firms usually go wrong when they try. ## The seven handovers in an engagement Strip away the methodology and every consulting engagement moves through the same sequence. What matters for software is not the stages but the handovers between them, because a handover is where information changes hands, and changing hands is where it changes. 1. **Conversation to opportunity.** Someone met a potential client, and the firm now needs to know who, what problem, and roughly how big. 2. **Opportunity to proposal.** Scope, approach, team and price get written down for the first time. 3. **Proposal to signed engagement letter.** The proposal is negotiated, approved internally and signed. This is the version that counts. 4. **Signature to kickoff.** The engagement becomes a project with a team, a plan, a budget and a deadline. 5. **Delivery to time and expenses.** People log hours and costs against the work, ideally against the right engagement. 6. **Milestone to invoice.** A phase completes or a month closes, and the firm bills for it. 7. **Invoice to payment, and to the next engagement.** The client pays, and the relationship either renews or goes quiet. In a typical stack, handovers 2, 3, 4 and 6 each cross a product boundary. The proposal is written outside the CRM, so the scope exists in a document and a summary of it exists in the deal. The project is created by hand from that summary. The invoice is built in the accounting package from a timesheet export. Nobody has to make a mistake for these to disagree; they only have to be updated at different times. The cost is rarely dramatic. It is the kickoff meeting whose real purpose is reading the proposal aloud to the delivery team. It is the invoice queried because it used last quarter's rate. It is the partner who cannot say whether an engagement is profitable until the month-end spreadsheet is done. We modelled the general version of this in [the integration tax](/blog/the-integration-tax/); in a consultancy it concentrates on the handover from sale to delivery. ## What "one system" has to mean Plenty of vendors sell a suite. A suite is several products under one login, often acquired separately, with connectors between them. That reduces the number of passwords. It does not remove the handovers, because each product still keeps its own copy of the client and its own idea of what the engagement is. For a consultancy, one system has to mean four specific things: - **One client record.** The account the partner is selling to is the same account the project belongs to and the same account the invoice is addressed to. Not three records joined by a name match. - **One engagement thread from deal to invoice.** The project opens from the won deal and stays linked to it. Time logged counts against the budget that was sold. The invoice reads the client, the terms and the lines from the same place. - **One permission model.** Who can see a client's fees, a consultant's cost rate or a draft finding is decided once, not per tool. - **One audit trail.** When a client disputes a rate or a scope change, you can see who changed what and when, without lining up three activity logs by timestamp. If any of those four is really a connector, you have a suite, and you will be maintaining the seam. ## A checklist for consulting firm management software Use these questions in any evaluation, whether the candidate is an all-in-one platform, a professional services automation (PSA) tool or a CRM with add-ons. The strong answer is the one you can watch happen in a demo, not the one on a slide. 1. **Can the pipeline stages match how you sell?** Discovery, proposal, negotiation and engagement letter are not the same as a generic sales funnel. You should be able to rename, add and remove stages without a consultant. 2. **Where is the proposal written, and is it linked to the deal?** If the answer is "attach a file", the scope lives outside the system. 3. **Is there an approval step before a proposal or engagement letter goes out?** Most firms want one, and most build it in email. 4. **Does a won deal create the project, or does someone retype it?** Ask to see the project's link back to the deal. 5. **Does time count against the budget that was sold?** Not against a separate project budget someone typed in at kickoff. 6. **Can you hold a bill rate and a cost rate per person or role?** Without both, the system can show revenue but not margin. 7. **Do expenses land on the engagement that incurred them?** Otherwise travel and subcontractor costs are allocated at month end, by hand. 8. **Can a milestone or a billing period draft the invoice for review?** A person should still approve it. Nobody should have to retype it. 9. **Can the client see progress and pay without emailing you?** A client portal answers half the status questions an engagement generates. We cover what belongs in one in [client portals for consultancies](/blog/client-portals-for-consultancies/). 10. **What does it hand your accountant?** Most consultancies keep a separate ledger. The export should arrive allocated to client and engagement. 11. **What does leaving cost?** Ask whether a full export of your data is free and how long it takes. 12. **What is the tool honestly thin at?** A vendor who cannot name a weakness has not been asked the right question. ## Where firms go wrong when they consolidate Consolidation projects in small firms tend to fail in a few predictable ways. **Moving everything at once.** The firm switches CRM, project tool, timesheets and invoicing in the same month, during a busy quarter, and the partners spend January reconciling two systems. Move in stages. **Recreating the old pipeline exactly.** The old stages were shaped around the old tool's limits. Consolidation is the one moment when it is cheap to redraw them. **Keeping the timesheet tool "for now".** Time is the input to budget, margin and invoicing. If it stays outside, the three numbers a partner most wants are still assembled by hand, and "for now" becomes permanent. **Buying for a firm five times your size.** Enterprise PSA tools do resource levelling, bench forecasting and multi-entity accounting very well. A twelve-person boutique pays for that configuration effort and uses a fraction of it. **Forgetting the accountant.** Nobody asks the person who closes the books until the first month end. Show them the export before you commit. ## A sensible order of migration Follow the money, one handover at a time. 1. **Clients and pipeline first.** Import accounts, contacts and open deals. Redraw the stages. This is where every later record attaches. 2. **Active engagements next.** Open each running project from its deal, with its budget and team, so new time lands in the right place from day one. Leave closed engagements in an archive export rather than migrating their history line by line. 3. **Time and expenses from a clean date.** Pick the start of a month. Everything before it stays in the old tool for reference. 4. **Invoicing last.** Once the time is trustworthy, let invoices draft from it, and run one billing cycle in parallel with the old process before you switch. 5. **The client portal once the data underneath is right.** Clients notice a wrong number much faster than staff do. ## How Cyril approaches it Cyril is built on the premise of this post: sales, projects, finance and the client portal are one graph rather than separate products, so the engagement is one record from deal to invoice. For consulting firms there is [a researched starting point](/solutions/management-consulting/), proposed at onboarding rather than imposed: a five-stage engagement pipeline, an approval rule before a proposal or engagement letter goes out, and two suggested automations aimed at the transitions that usually stall. You accept, edit or drop each one. In practice, [Sales](/product/sales/) holds the accounts, contacts and engagement pipeline. A won deal can open the project in [Projects](/product/projects/), with time logged against the engagement budget and rate cards holding bill and cost rates, so each project shows its margin. [Finance](/product/financials/) drafts an invoice from the deal's lines or from a completed milestone, for a person to review and send, and expenses captured from receipts land on the project that incurred them. The [client portal](/product/client-portal/) lets clients follow their projects, sign proposals and pay invoices, and portal users are free. How the pieces join is set out in [CRM with projects](/product/crm-with-projects/) and [CRM with invoicing](/product/crm-with-invoicing/). What it is not, stated plainly: it is not a general ledger, so bookkeeping and statutory accounts stay with your accountant, and firm-wide utilisation and bench planning across a large consultant pool is thinner than a dedicated PSA tool. Treat that as absent. Cyril is also pre-launch, opening to founding members from the waitlist first. ## Common questions ### What is the difference between a PSA tool and an all-in-one platform? A professional services automation tool is built around delivery: resourcing, time, utilisation and project accounting, usually with a light CRM attached or a connector to one. An all-in-one platform puts sales, delivery, finance and client access on one data model. A PSA is stronger at portfolio resourcing; an all-in-one platform is stronger at the handover from sale to delivery and at answering questions that cross both. ### How long does consolidating a small consultancy's tools take? It depends on how much history you migrate, and that is the variable most worth controlling. Moving clients, open deals and active engagements is a far smaller job than migrating every closed project's timesheets. Most of the risk sits in running two systems in parallel for too long, not in the import itself. ### Do we need to replace our accounting software? Usually not, and you probably should not. Consulting firm management software should cover invoicing, payments, expenses and engagement profitability, and hand clean, allocated exports to the ledger your accountant already uses. ### Is one system worth it for a firm of five people? The seams are the same at five people as at fifty; there is simply nobody whose job is to maintain them, so the partners do it in the evening. The case for one system is often stronger in a small firm, provided the tool does not demand enterprise-scale configuration. --- If you want to be among the first to use Cyril, [join the waitlist](/waitlist/).