The deal and the invoice are the same customer
In most stacks they are not. The CRM holds the deal, the finance tool holds the invoice, and the only thing joining them is somebody typing the same numbers twice. Cyril treats them as one record seen from two angles, because invoicing reads directly from the deal rather than from an export of it.
What that means on an ordinary Tuesday
A closed deal becomes an invoice without re-entry
The amount, the currency, the line items and the customer are already on the deal. Invoicing reads them rather than asking for them again, so there is no window in which the two disagree.
Forecasting reads pipeline and delivery, not a copy of them
Revenue forecasting sits on the same graph as the deals and the projects it forecasts from, so it reflects what actually changed this morning rather than what last synced overnight.
One customer, so one answer to "what do they owe us"
The unpaid invoice is attached to the same account the pipeline is on. Nobody has to decide which system to trust, because there is only one place to look.
The AI can answer across both
A question like "which accounts closed this quarter and have not paid" crosses the two in a single query. In a two-tool stack that question is a project, so it gets asked quarterly at best.
What two separate tools do instead
Two tools can be made to pass records to each other, and plenty of teams do it well. What a connector cannot create is a shared idea of what a customer *is*. So the CRM has its own notion of the account, finance has another, and the gap between them is filled by convention — a naming rule somebody remembers, a spreadsheet that maps one to the other, a monthly afternoon spent working out which is right. That is the cost the licence line never shows.
Whether this is for you
A good fit if
You sell work and then bill for it, your invoices are built from what was agreed in a deal, and the person raising the invoice is not the person who closed it. That handover is where the re-keying and the disagreements live, and it is what one record removes.
A poor fit if
Your billing is genuinely independent of your pipeline — high-volume transactional invoicing, or a finance function with its own system of record it will not move. The seam this page removes is not the seam costing you money.
What this does not do yet
Cyril is pre-launch, so the useful thing to publish is the edge of what exists rather than a roadmap. If one of these is a hard requirement, say so early and we will tell you plainly whether to wait.
- It is not a general ledger, and is not trying to be. Bookkeeping, tax filing and statutory accounts stay with your accountant; exports exist for that handover.
- Revenue recognition beyond straightforward invoicing and forecasting is not covered. If you need deferred revenue schedules, treat that as absent.
- Multi-entity consolidation is not something to plan around today.
The modules this uses
Both are part of the platform at one per-seat price — there is no bundle to assemble and no connector to buy. Each page below covers what that module does on its own.
Common questions
Does this replace my accounting software?
Not the ledger. It covers invoicing, payment capture, expenses and forecasting on the same records as your sales and delivery work, and exports for your accountant. Bookkeeping and filing stay where they are.
What if we already have a finance tool we like?
Then the honest answer is that the gain here is narrower for you. The argument on this page is about removing the seam between two systems; if you keep a separate finance tool, the seam stays and something has to maintain it.
Is invoicing a separate cost?
No. Pricing is per staff seat and includes every module, with no base platform fee and no per-app upsell. Client portal users are free and unlimited.
Be one of the first to use Cyril.
Join the waitlist for early access. We'll only email you when there's something real to share.