Why We Built CypherTax

This is something that should have been done a long time ago.

The average cost to implement sales and use tax systems steadily rose over the past two decades. But the costs weren't due to the time necessary to implement the steady stream of product improvements we've seen added during that same period of time. Instead it is often due to the many moving parts outside of the control of the tax portion of implementations, and how the upstream and downstream processes were often locked-in before tax had an opportunity to provide their requirements.

Tax wasn't budgeted during the ERP implementation?

A seat at the table costs less if incorporated at the onset.

Tax functionality is often a check box left empty when proposals come in for an ERP implementation. With so many moving parts its easy to miss when the tax department isn't included in the process to determine the system integrator. A seat at the table costs less if incorporated at the onset. Even when tax is included it's often not treated as a workstream like other areas of the business.

The system integrators often prefer specific functions to be deployed throughout the project. The challenge is that the tax functionality is perceived as an unnecessary cost, partly because simple math is applied as factors when determining the number of workstreams. But tax doesn't have to be treated the same way, though simple math is often easier than the alternative.

Sometimes the thought is that it would be easier to get a change order later, after the bid is won, than to be forward thinking. Fortunately not all companies think this way, and view tax scope as a differentiator. Even when the companies factor in tax it's still often the area that's underserved, leading to some of the same issues that occur even when left out of scope.

‍

Master data team left tax out of the workshops?

When master data is locked down, is there another way you can get what you need?

Tax systems can only function properly when other key areas are sensitized for tax purposes. One of the frequently areas that are limiting for tax is master data. When master data is locked down, is there another way you can get what you need? There is, but its often addressed with data editors which can cause reduced performance.

Settling for the best achievable result based on the lack of tax sensitized data should never be considered an acceptable risk, so we factored that limitation into our design.

We don't want you to wait until the realization phase of a project to learn you have a problem.

Tax personnel integrated into a project is an effective approach when you know it can be a problem later. But many companies don't realize tax participation was required earlier, but now that fear can be mitigated. Years of experience with clients trying to address tax process gaps due to technology drives us constantly, solutioning each gap in practical and repeatable ways.

Being system agnostic has it's benefits.

Product certification is a way to control capabilities, the identification of the lack of.

The CypherTax origins were in ERP specific applications that were embedded within the ERP. We realized early on that we were contributing to that rabbit hole of forcing clients to fit a solution, as opposed to creating solutions that fit clients. Product certification is a way to control capabilities, the identification of the lack of. We designed CypherTax to extend outward to the point where a simple process completes what would otherwise be an integration.

In doing so, we created a framework of functionality that is agnostic to the ERP and can be easily configured regardless of where the data came from, and where it's going. This enabled us to focus less on piles of paperwork, and more on flexible capabilities.

‍