These came up on real calls with CPA firms. The answers are what we tell them, including where a system has limits and where the honest answer is that it depends.
No. CCH Axcess does not offer a sandbox, so every integration is built and tested against the firm's live database. We test on a small sample of records first, keep a log of every change, and only then run at full volume.
Yes, but it doesn't cover everything. Client, tax, and document data are available through the API. Some functions, including time entry import in CCH Axcess Practice, have no API at all. For those we use a bot that works through the same screens your staff use.
It is a separate API credential for outside developers, announced by Wolters Kluwer in September 2026. Before it, a vendor had to use the same key as the rest of the firm. A dedicated key lets the firm identify, authorize, and govern each integration separately.
Yes. We run a one-time bulk migration that keeps folder structure and metadata, skips documents past the retention period unless they are marked permanent, and then keep new files in sync through the API. Staff can keep working in CCH Axcess while the firm adopts SharePoint at its own pace.
Yes. We have built this for Financial Cents at two firms. Time entries cross every day. Each staff member reviews their own entries first, and then a bot imports them. Billing, WIP, and realization stay in CCH Axcess without anyone re-keying.
Usually not out of the box. CCH Axcess has few ready-made integrations compared with newer platforms such as Karbon, which were designed from the start to connect to other software. For planning, assume a connection will have to be built rather than switched on, and budget for it.
Usually yes. The data sits in a solid database, so a custom report is typically a quick turnaround. The built-in client reports are limited: a standard client list gives the ID, the name, and one email address. Every email, full mailing addresses, and other detail in one place takes a custom report. Project and workflow reporting is stronger.
It is an add-on that copies your CCH Axcess data into a database, which makes extracting and reporting on it far easier. With it, most data questions are straightforward. Without it, some data is still reachable but several things get much harder, so it is one of the first things to establish on any CCH data project.
Question it before carrying it forward. These schemes were often designed when the firm was much smaller, and the ranges get stretched as the firm grows. Ask whether it still helps you manage the client list or is followed out of habit. If you keep it, have the system assign the number, because a manual step there cascades into everything downstream.
Karbon's API has no endpoints for WIP or documents, so there is no supported migration path for them. We built a browser automation that migrates and links them, with a staged import so nothing has to be relinked one by one.
We implement Anchor, StanfordTax, Truss, RingCentral, Zapier, and custom Power BI reporting alongside Karbon. We also build custom connections to CCH Axcess, UltraTax CS, SharePoint, and QuickBooks Online where no off-the-shelf integration exists.
Yes. When a client is onboarded in Karbon, the matching SharePoint folder is created with a consistent structure and permissions. Files are tagged with client ID and tax year, and flat views let staff see every document for a client in one list.
Yes, through an MCP server. It is a governed connection between an AI assistant and Karbon. Staff can ask “which clients are missing an email?” and get the list. The server controls what the AI can see and do, and logs every request.
At the contact and client level only. Karbon has no custom fields on work items or projects. CCH Axcess allows them at both the project and the client level, so anything you record per project today has nowhere equivalent to land. Decide early whether to move it up to the client level or let it go.
Only partly. Karbon has two built-in positions on a client, client owner and client manager, and they cannot be relabelled. If your current system records more roles, either create custom fields to carry them or accept dropping them. Neither is wrong, but make it a conscious decision while mapping the data, not a discovery afterwards.
No, by design. The client interacts with Karbon, not with your document storage behind it. They upload to you, and the routing into the right SharePoint or network folder happens on your side. Most firms prefer that once they think it through, because a client cannot file something in the wrong place.
Yes. Bulk linking is a data management exercise and is generally straightforward. It is not one of the hard problems in a Karbon migration.
No. UltraTax CS is desktop software with no API. The only way to automate it is through the screen, the way a staff member uses it. Our bots sign in overnight, run the same reports a person would, and pass the results to other systems.
Yes. A bot reads UltraTax reports and updates Karbon through Karbon's API. The client listing creates and updates contacts. The return list creates tax work items. Rejected e-files update the work item and alert the right person. Printed returns are uploaded to the work item or client portal.
UltraTax reports are cumulative. They list everything that ever matched, not what changed today. The automation keeps its own record of what it has already handled and acts only on the difference, so running it twice has the same effect as running it once.
No. Print once and let the automation distribute. The output goes to the work item in the practice management system first, and from there to the SharePoint folder and the network drive. Returns prepared before the automation went live are picked up in a single one-time backfill, with nothing reprinted.
It was built to run on-premises and does not expose an API. Data can still be extracted and landed in a cloud database. To show it inside another system, that system needs a door: a real integration, or at least a custom field to write into. The realistic pattern is extract-and-push, not a live link.
No. The data is the straightforward part. Retraining experienced preparers on a different package is the bigger lift. Proving the new package handles your returns is the other: a simple 1040 looks fine anywhere, and the differences appear on complex returns, such as a US person abroad with foreign accounts. Evaluate with your genuinely complex returns.
Not entirely. Build the migration in two halves with a staging area in the middle. The half from staging into the destination system is common and gets built once. The half from each source into staging is different every time, because every source stores things differently. Each new migration gets faster as source connectors accumulate.
Sequence the migration around it. Clients with no open WIP move first and cleanly. For the rest, work WIP down toward zero before their cutover, so part-finished work and its balances are not carried across. That needs live data, because balances change daily, so data access is the first thing to request.
Two components. The data component moves client records, project lists, and billing history. The process component decides how the firm will work afterwards, and it is the one that gets underestimated. Show leadership what the end state looks like, agree a plan against it, and only then build and take it to the wider team.
It varies enormously, so check before committing to a timeline. CRM platforms such as Salesforce are comparatively easy to extract from. Practice management and tax products are generally the hardest, because their data models are complex and their export options are limited.
For documents arriving by email, each message carries a unique identifier in its header that can be read quickly and cheaply. Checking it before processing prevents duplicate files being filed and avoids paying to process work that is already done.
Not as one flat list of fifty categories. Use two steps: identify the broad domain the document belongs to, then classify within that domain. The narrower second decision is far more reliable. Base the design on real volume too: analyse about a hundred real documents to see which types dominate and to validate against.
With your most complex case, not your simplest. Pick the client with the largest number of forms in the category and run that first, because a simple case will pass and tell you nothing. Validate the result internally before anything goes to a client.
CCH Axcess through the Data Axcess Utility, Practice CS, Karbon, QuickBooks Online, and payroll systems such as Paylocity. Firm KPIs sit on top. Client, staff, and AR detail sit underneath. Any number can be clicked through to the transactions behind it.
It depends on scope. A quick report on data you already have usually takes a few days. A mid-size dashboard usually takes two to three weeks. Pre-built templates for firm KPIs, client profitability, staff productivity, WIP aging, and AR shorten the start. The time goes into fitting it to your firm: your realization formula, your offices, and your partner groupings.
A common cause with CCH Axcess is credentials that expire every 60 to 90 days, which breaks the refresh each time. We move the reporting to centrally managed infrastructure and add monitoring that reports a failed refresh before partners notice.
No. People reading a report view it in the browser, which is what it is designed for. Power BI Desktop is the authoring tool. The person building the report needs it, and the people reading it do not.
Visibility you can act on. You see which projects are overdue at a glance and adjust dates straight away. Over the season, short regular reviews show which steps keep causing trouble and are worth automating next. Run it through a full season before redesigning the underlying data, because the season tells you what you need.
Yes, if the data is captured consistently. When staff log a short time entry against a quality-control task type with a note about the issue, it becomes reportable: every work item that had a quality issue, what it was, and what was done about it. It can be its own page or a toggle on the main dashboard.
No modern one. Practice CS is a desktop system on a SQL Server database, and the database is the way in. Invoice descriptions are stored as rich-text formatting, so they have to be cleaned before they are usable numbers and text again.
Yes. Clients and invoice lines move automatically, with configurable tax handling and email-based matching that catches near-duplicate names. On one engagement roughly 1,700 clients were synced in testing and then in production, which ended manual re-entry.
Not on its own. We add a monitor that flags entries below threshold or past deadline, reminds the staff member directly, and escalates repeat patterns to their manager. WIP is then right on the day, not a week later.
Yes. The forms are read with OCR, checked against the prior-year return and your rules, and entered by a bot on the same screens your preparers use. Anything the bot isn't sure of goes to a person. Firms running it measured 3 to 8 hours of keying removed per return.
Yes. Extensions are filed in batch from a list, and each confirmation is logged. E-file status is checked on a schedule and written to your tracker, so nobody has to log in to check each return.
Rarely in the most sophisticated place. Removing a step where someone retypes information from one system into another, or where a document is printed or filed twice, usually pays back faster than anything clever. Those steps happen many times a day, and each one is a chance to introduce an error.
Many are not, and that is a legitimate position. Establish where the firm stands early, because it changes the design. Rules-based automation is safer and more predictable but takes more work to change later. An AI-assisted approach is more flexible but means a general-purpose model reads client material. The decision belongs to the firm.
It depends on what your environment and licensing allow. A proper setup has separate development and production environments, with changes packaged and imported between them. Where that is not available, the fallback is to develop and test the change, get it approved, then apply it to the production flow by hand. That manual step is where mistakes get introduced.
Steven Duc Tran, a CPA and Certified Internal Auditor. He worked inside CPA firms from 2013 to 2017 and has consulted on accounting-firm technology since 2017. Silver Sea has served 50+ firms. It is based in the US and also takes on firms in the UK, Europe, and Australia.
With a discovery call. When a project has unknowns, the next step is a small fixed-fee discovery phase. We study the systems, run the experiments, and measure the complexity. You get a realistic timeline and an honest answer on whether we should take it on, before you commit to the build.
Every engagement is confidential. A case study necessarily describes a firm's operational weak spots or its technology advantage, so we describe the firm and the numbers without naming it. Named testimonials appear only where the client has chosen to give one.
Ask it on a call. If we don't know, we'll say so, and tell you how we'd find out.