Say what you want
Plain words, the way you would ask a colleague. No menus, no field names, no tab-switching into another tool's interface.
Composer is the chat where a CPA firm runs its day in plain words. Win the engagement in Ignition, set the client up in Karbon, bill and chase in QuickBooks Online, all from one place, without learning three interfaces. Before anything touches a live proposal, work item or invoice, you get a card showing exactly what will change, down to every field and price.
draft a proposal for Acme on the FY26 advisory retainer
Plain words, the way you would ask a colleague. No menus, no field names, no tab-switching into another tool's interface.
Composer comes back with a card showing the action and every value it will send: the client, each service, the prices, all of it. The whole shape is checked against your system before you see it. A card you are asked to approve is one that will actually work.
Nothing reaches your books until you tap Approve. When you do, it happens immediately, and the card tells you plainly that is the case. Want it different? Say so, and a corrected card replaces the old one. Only one is ever live at a time.
No firm gets Ignition, or anything else, switched on by default. You say "connect Ignition" in your Composer, sign in on Ignition's own page, and it is on for your account. Most of what a firm runs on is a connector away like that, and anything with an API is a build away. What differs is how far each one goes once it is in.
These are the shapes of work a CPA firm runs every week. Each one is an ask you type into Composer. Reads come back as answers. Writes come back as a card you approve. Anything your own login can do in Ignition, QuickBooks Online or Karbon is on the table.
Every practice has a few. The monthly pack that takes a junior a day, the renewal sweep nobody remembers until a client lapses, the handover between whoever sells and whoever delivers. Describe it on the walkthrough and we will tell you straight whether it is a connector or a build.
Bring us the workflowComposer reads your account's real list of available actions before proposing anything, so it is never guessing at what your system can do or what a field is called. Client names above are examples.
Everything your own login can do, Composer can propose. Everything it can't, it can't.
You approve access on your provider's own sign-in page. The connection then inherits your role, so it can never see anything your own login cannot.
Every change is proposed as a card first. Approve it and it happens immediately. Ignore it and nothing at all has changed.
If a change needs a value Composer does not have, a price or a particular client reference, it asks you rather than filling in a plausible guess.
If your system refuses a change, you see its own words on the card, and nothing will have been altered.
Ask for a correction and the old card is replaced, not stacked. There is never a queue of half-approved changes to untangle.
Composer can draft and create. Putting a proposal in front of your client is still a deliberate act you take yourself.
Composer sits inside a shared board where your requests become tickets your team and ours can both see. When something needs judgement, a human picks it up and answers on the ticket, in their own name.
Anything important gets checked by a real person before it ships. That is not a fallback for when the agents fail; it is how the whole thing is set up.
Tell us what your practice runs on and which of the workflows above eats the most partner time. We will run it on a sandbox, approval cards and all, before anything points at a real client file.