A client accepts a proposal in Ignition. The engagement is agreed, the billing terms are set, and the work can begin.

Then the rest of the firm's systems have to catch up. The client has to match the right record in QuickBooks. The agreed services have to become work items in Karbon. Invoices have to follow the right billing schedule, and someone has to deal with the cases where the information doesn't line up.

Ignition's native integrations already automate much of this. The harder part is knowing what each connection handles, and where extra configuration or development is worth the cost. (If you know the product as Practice Ignition, it's the same platform under its current name.)

Below, you'll find how the main connections compare, how the integration methods differ, and a worked proposal-to-billing example that shows what a reliable implementation has to get right.

Which Apps Integrate With Ignition?

Ignition connects with accounting software, tax platforms, practice management systems and automation tools. Its official integration directory lists them, and the listing tells you a connection exists. The way information moves through it is a separate question.

For an accounting firm, the useful distinction is between three jobs: moving client information, creating financial records, and starting operational work. These are among the most relevant connections:

The scope varies widely. Some connections automate financial transactions, some create practice-management work, and some mostly synchronize client data. That difference should drive your choice.

Accounting and Payment Integrations

Ignition's QuickBooks and Xero integrations create invoices once a client accepts a proposal. Services set up for billing on acceptance produce an invoice at that moment, and recurring services follow their configured schedules. You don't need custom development to raise an invoice after a proposal is accepted.

Ignition also handles payment reconciliation. Its Net Settlement capability, for example, deals with payment collection fees and matches transactions in connected QuickBooks and Xero accounts.

So the implementation questions are about your firm's own billing arrangements:

• Does the proposal name the correct legal entity?
• Are services mapped to the right accounting records?
• What happens when the billing schedule changes?
• How do refunds, reversals and disputed payments flow through?

Test these against what Ignition already does before anyone proposes more software. Sources: Ignition + QuickBooks and Ignition + Xero.

Practice Management and Workflow Integrations

Ignition also connects engagement information to the applications firms use to run delivery.

The Karbon integration creates work items from the services in an accepted proposal, and you can map those services to existing Karbon work templates. The work item's budget comes from its Karbon template, and Karbon manages any recurring work after the first deployment. Ignition starts the work, and Karbon runs it from there.

Xero Practice Manager offers similar work creation, with its own client synchronization and job-template settings.

A work item existing in Karbon tells you the work was created. The firm may still need an internal approval, a document check or information from another application before anyone starts. Whether that calls for more automation depends on your operating rules and what your current systems already enforce.

Regional Availability and Licensing

Integrations vary by market and by subscription. ProConnect matters mainly to US tax practices, and the newer Practice CS Connector is offered to eligible US firms as a paid add-on.

In the UK, Ignition provides a connection to Sage Business Cloud Accounting.

Before you plan an integration, confirm the supported country, the subscription, the permissions required, and whether the specific features you need are available to you. A plan built around a connector your firm can't use will stall at the first step.

What Syncs Between Ignition and Your Other Systems?

"The two systems are connected" hides several decisions. Which application owns the client record? Where should someone make a change? Does information move at once or on a schedule? What happens when a record already exists at the other end?

Your answers decide whether the integration supports the business process or becomes one more source of inconsistent data.

Client Records and Data Ownership

Take the Ignition–ProConnect integration. According to Ignition's documentation, client information synchronizes from ProConnect into Ignition once a day, and nothing flows back.

In practice, ProConnect stays the authoritative source for the information it supplies. The same principle holds for every integration, even where the sync rules differ: for each important client field, decide which system controls it and how your team handles a conflicting change.

Duplicates need the same attention. Ignition lets you link ProConnect records to existing clients so it doesn't create new ones, and a reliable process keeps those links intact when client details change.

Proposals, Services, and Work Items

The Ignition–Karbon integration shows where a connection's boundaries sit. With the right automation on a proposal, Ignition deploys Karbon work items from mapped services and templates.

Several details stay in Karbon. The work template sets the budget, and recurring work follows Karbon's configuration. Ignition's interface also doesn't show a direct reference to the Karbon work item it created. All of this is documented product behavior. Source: Karbon and Ignition integration documentation.

Now picture a firm that needs to track every accepted engagement against its own delivery-approval process. It wants to link each engagement to its work record, check the necessary information, and record when the engagement is ready for delivery. The existing Ignition–Karbon connection stays the starting point, and any added logic covers only the confirmed requirement the connection leaves open.

Invoices, Payment Status, and Reconciliation

Financial data needs one more set of distinctions. An invoice, a paid status, a payment transaction record and a bank settlement are four different facts, and each one answers a different question.

Ignition's native accounting integrations already create invoices and support important reconciliation work, including the documented Net Settlement handling of payment fees and related entries in QuickBooks and Xero. Build nothing that repeats this without a specific reason.

The distinction matters most once developers start working with Ignition's APIs. Ignition can notify an external application when an invoice is paid in full, and, as the next section explains, its API won't hand over the underlying payment records. Any system designed around payment information has to plan for that.

Native Integration, Zapier, the Ignition API, Reporting API, or MCP?

Ignition offers several ways to extend it, and each solves a different problem. The right choice depends on what you need: configure existing functionality, react to a business event, read information, change records, or work through an AI assistant.

When Native Integrations or Zapier Are Enough

Start with the existing integration. If Ignition already creates the right invoice, matches the right client and deploys the right work, new code adds cost and solves nothing.

Zapier covers many supported events and actions. An accepted proposal can trigger an action in another application, for instance to notify an internal team or start an administrative step. The workflow still needs rules for matching records, handling incomplete information and recovering from failed runs, and none of that requires a standalone custom application.

Weigh the whole implementation, including monitoring and maintenance, and pick the least complicated approach that meets the requirements and holds up when exceptions arrive.

What the Ignition API Covers, and What It Leaves Out

The Ignition API, which Ignition previously called the Core API, opens custom integrations beyond the packaged connections. As of October 2026, it's available in Early Access on every Ignition plan, free while in Early Access, and any Admin can switch it on from Labs.

It reads and writes clients and contacts, proposals and their content, invoices and services. A custom application can create or update proposals, send them, create and void invoices, and generate a payment link for an invoice.

Several areas sit outside it entirely: payment records, billing items, deals and pipeline stages, forms, and the terms, email and message templates. It also never returns files, so proposal PDFs, signed documents and uploaded attachments stay inside Ignition. Proposal content is available, which is different from the signed document itself.

That sets a clear boundary. A custom integration can create an invoice through the Ignition API and give the client a way to pay it, and it has to find payment records somewhere else. If your workflow depends on those records, assess it against the other supported capabilities and systems before you build.

Treat the API as a defined set of operations and design around what it supports.

When to Use the Reporting API or MCP

The Reporting API serves a different purpose. It extracts data for analytics, dashboards and external reporting. It's read-only, so it can't update clients or send changes back into Ignition.

The Ignition MCP lets connected AI assistants work with the platform. An assistant can take supported actions within the permissions and capabilities of the connected user, and some actions, such as issuing invoices, require review and confirmation. That suits preparing proposals, finding records or reviewing information. A financial integration that has to process every event the same way, with nobody in the loop, belongs on the API and webhooks.

Choose the mechanism by the action it has to perform.

A Proposal-to-Billing Workflow: Where Additional Logic May Be Needed

Take a US accounting firm that runs four systems:

• Ignition for proposals, engagement terms and billing
• QuickBooks Online for accounting
• Karbon for practice management
• An internal review process for delivery readiness and exceptions

The firm wants an accepted engagement to flow into billing and delivery without anyone retyping data. The scenario is illustrative, built to show the decisions involved.

Step 1: A Client Accepts a Proposal in Ignition

The client signs a proposal for two services: a one-time advisory assessment billed on acceptance, and a recurring monthly accounting service. The proposal defines the services and the billing rules.

Once the client accepts, Ignition starts the billing those rules call for. The one-time service can produce an invoice straight away, and the recurring service follows its schedule. Nothing so far calls for custom development, because Ignition's native billing is built for these events.

Step 2: Existing Integrations Create the Financial and Operational Records

With QuickBooks and Karbon connected, Ignition creates the invoice in QuickBooks and deploys the work items into Karbon.

The first decision concerns identity. Say the engagement is signed by Northstar Holdings LLC, and the approved billing entity is Northstar Operations LLC. The QuickBooks integration matches clients by name and also supports explicit client mapping. Without the right mapping, the invoice could attach to the wrong record, or Ignition could create a new client. Confirm the approved billing entity before you rely on the automated result, especially for clients with several legal entities.

The second decision concerns work creation. Ignition deploys work items from mapped Karbon templates, so check that the right template and assignee are selected, and that the template's budget and recurrence match the engagement. These checks confirm the existing capabilities fit your engagements, and they give you no reason to rebuild them.

Step 3: Identify the Requirement That Remains

Now add one operating rule. The firm wants its delivery team to start the advisory assessment only after someone has reviewed certain documents and an internal manager has approved the engagement for delivery. That requirement sits apart from accepting the proposal and issuing the invoice.

The process has to tell four states apart:

Engagement accepted: the client has agreed to the services.

Billing initiated: the financial action is complete or scheduled.

Work created: the operational record exists in the practice-management system.

Ready for delivery: the firm's own review conditions are met.

Each state records a different fact. A finished action in one system says nothing about whether the whole process is ready.

Before building anything, the firm should check whether its current tools can enforce the review through configuration. If they can't, the readiness step becomes a candidate for an additional integration.

Step 4: Design the Extension Around the Existing Workflow

One approach uses Ignition's proposal.accepted webhook event. On receiving the event, a custom service identifies the accepted proposal, links it to the right client, and checks the supporting information held in authorized systems. It then decides whether the firm's review conditions are met, or whether a manager needs to look into an exception.

The extension leaves the invoices and Karbon work items to the native integrations. Its job is to track those existing records alongside the firm's own approval state, which means keeping relationships between several business objects:

These describe what the design has to track. The actual API field names need checking against Ignition's documentation.

Timing matters too. The acceptance event can arrive before every downstream operation has finished, so the extension can't assume the invoice or work item exists yet when it receives the event. A sound design checks for the records it needs, retries safe reads where that makes sense, and sends unresolved inconsistencies to a person for review. Validate the exact operations against the available APIs.

Step 5: Prevent Duplicates and Handle Failed Events

Event-driven integrations bring their own requirements. Ignition's webhook documentation lists events including proposal.accepted, invoice.created, invoice.paid and invoice.updated, and it states two things your design has to absorb. Events can arrive out of order, and the same event can arrive more than once.

So the receiving system needs a way to recognize work it has already done. Processing the same acceptance twice shouldn't create a second review request, duplicate a financial transaction, or repeat an irreversible action. Each delivery carries a timestamp of when the event occurred, which lets you rebuild the right order, and a field showing what caused the change, which lets your integration skip events it triggered itself and avoid running in a loop.

Failures need deliberate handling as well.

If the endpoint recovers inside that window, the delivery still arrives. Events missed while a webhook is off are never delivered later, and Ignition can't re-send past events, so restoring the connection won't bring them back. Ignition's guidance is to read the current state from the API instead, which means your design needs monitoring and a recovery process that compares the current state of Ignition with the connected systems.

Security is part of the same job. Ignition signs every webhook delivery, and the receiving system should verify the signature and reject old deliveries before accepting a message. Ignition suggests a five-minute tolerance, which stops anyone from replaying an intercepted delivery. These are responsibilities your implementation has to carry, and an endpoint alone takes on none of them.

Step 6: Test the Complete Process

Test the implementation against the conditions most likely to produce wrong records or unfinished work.

Run these tests whichever approach you choose: native, configured or custom.

Set the acceptance bar at three things: the correct records exist, the required conditions held, and your team can resolve every exception without losing control of the process. An invoice and a work item appearing proves much less.

Ignition Integration Checklist Before Go-Live

Before your firm relies on a new integration, confirm five things.

1. Confirm Data Ownership and Client Mapping

Decide where each important record lives. For client information, name the authoritative system and how updates move. For financial information, separate the engagement entity from the billing entity. Plan around ProConnect's daily one-way sync, and confirm the intended customer mapping in QuickBooks.

Clients with several legal entities need explicit mappings, since identical names can point to different companies.

2. Review API Permissions

An Ignition API integration acts as the person who approved it and inherits that person's access. Admin and Member users are the only roles that can make changes through the API. Sales, Billing and Viewer users are read-only there, even though some of them can do more in the Ignition interface. With Advanced roles and permissions turned on, each permission on the user's role applies to the API as well.

Each app also receives the whole API, with no way to restrict it to certain areas, so the user's role is your main control. Settle who approves the connection, what the integration can change, and how your team protects the credentials. If you build a separate application on top, it has to enforce its own permissions for the people who use it.

3. Test Webhook Security and Recovery

Check that incoming events are authenticated and that your system copes with duplicates, out-of-order delivery, temporary outages and interrupted subscriptions.

Write down what happens when the webhook comes back after downtime. A successful reconnection restores the connection, and your recovery process still has to confirm the business records are consistent again.

4. Validate Billing and Payment Exceptions

Test well past the clean invoice: partial payments, refunds, reversals, failed collections and unexpected client mappings.

Start with what Ignition already supports. Its QuickBooks and Xero integrations include reconciliation, with documented handling of payment fees. The aim of testing is to confirm your firm's own accounting rules are supported, before anyone plans a second application to repeat the native reconciliation.

5. Confirm Regional and Operational Requirements

Check subscription eligibility, regional availability, required add-ons and system permissions.

The Practice CS Connector shows why. It already supports two-way invoice synchronization, client and service mapping, payment posting as receipts, and handling of certain duplicate or unresolved records, and it's offered to eligible US practices as a paid add-on. A firm that uses Practice CS should evaluate it before commissioning custom work to recreate it. Source: Practice CS Connector overview.

Last, name the people responsible for monitoring, failed-record review, credential upkeep and future changes. Someone has to own the integration after the first setup works.

When Does Custom Ignition Development Make Sense?

Custom development makes sense when an essential requirement stays unsupported after you've evaluated the native integrations and configuration options. These situations deserve a closer look:

A workflow depends on several systems reaching one coordinated decision. Delivery readiness, for example, can depend on the accepted engagement and on information kept elsewhere.

A required operation is missing from the integration you chose. Check whether another supported method covers it before proposing development.

Your firm has specific approval or validation rules. These may cover client identity, engagement changes, document requirements or internal authorization.

Existing monitoring or exception handling falls short of what operations need. Write down the missing capability in specific terms.

The process needs ongoing engineering ownership. A multi-system workflow needs someone responsible for its integrations, testing, support and future changes.

Each of these justifies investigation, and the answer may still be better configuration, a Zapier workflow, a limited API extension, or a separately maintained service. Compare the full cost of each option, including licensing, development, testing, monitoring and support. For a broader framework, see our guide to accounting automation software: build vs. buy.

The useful starting point is one handoff your existing systems don't complete the way your firm needs.

Need to Connect Ignition to a Workflow That Doesn't Fit the Standard Setup?

An accepted proposal should lead to the right financial and operational results. Ignition already provides much of what that takes, and the remaining work depends on how your firm manages client information, billing, delivery and exceptions across its systems.

Codebridge helps accounting firms design and build connected workflows around the software they already use. Start with one process that still needs manual coordination: what your existing integrations cover, what remains open, and whether more engineering is justified.

Book a 30-minute call