IT Services ERP Consultant, USA

Sales tax when one contract mixes hardware, software and labor

A typical US managed services invoice carries several kinds of charge at once: a monthly per-user fee, a few resold cloud subscriptions, a replacement laptop and some project hours. States treat those categories differently. Some tax prewritten software or digital services, some tax certain IT services, and many have specific rules for what happens when taxable and nontaxable items are sold together for one price. Your tax advisor decides the treatment, and the system design has to be able to carry it out.

In practice that comes down to three design choices:

• Itemization: whether an all-inclusive agreement is invoiced as one line or split into components, and how that split is documented in the agreement itself.
• Service location: clients with sites in different states need tax determined per location, not only by billing address.
• Tax engine or native tables: firms selling into many states often connect a sales tax service to the ERP rather than maintain rates by hand.

I capture these as requirements before any configuration, because changing how agreements are itemized after go-live means reissuing contracts as well as reconfiguring invoices. For the broader American context, including entities registered in several states, see my US ERP consultant page.

Co-managed IT: where your scope ends and theirs begins

More US mid-market clients now keep a small internal IT team and buy specific services from an MSP: monitoring, security operations, after-hours coverage or escalation for difficult problems. Co-managed agreements are where billing disputes start, because the line between what the MSP covers and what the internal team owns is rarely written down in a form the service desk can use.

When I map these arrangements, I turn the agreement into a responsibility list per service: who receives the alert, who works the ticket, when an escalation becomes billable, and whose time counts against any included hours. Each of those becomes a ticket type or a contract rule rather than a sentence buried in a PDF.

The same exercise pays off for fully managed clients. A classification scheme with a handful of clear categories, such as covered, billable at the agreement rate, project work and goodwill, lets engineers decide quickly and lets finance trust the result. I also define who reviews billable time before it reaches an invoice and how disputed items are credited, so the account manager is not renegotiating every month.

Where your PSA already handles agreements well, this work goes into its configuration, and the ERP receives approved charges rather than raw time entries.

Clients in regulated sectors and public agencies

American MSPs that serve medical practices, financial advisors, law firms, school districts or local government carry obligations that reach into their back office. A healthcare client will typically require a business associate agreement before you touch systems holding patient data. Defense supply chain clients may ask you to support their own security compliance work. Public agencies buy through purchase orders, cooperative contracts or approved vendor lists, and often set strict rules on invoice format and supporting detail.

For the ERP, this translates into practical requirements:

• Agreement records that store the compliance documents signed with each client and turn their review dates into tasks, not just attached files.
• Ticket and change history retained so you can show what was done, by whom and when, if a client's auditor asks.
• Purchase order numbers carried from quote to invoice for public sector and larger corporate clients.
• A clear statement of where your own systems host client information, since some clients ask that their records stay within the United States.

I do not give legal or compliance advice. I make sure the obligations your counsel and clients define are reflected in the system design, so evidence comes from records rather than from a scramble through inboxes.

Leaving QuickBooks and spreadsheet billing behind

Many US MSPs start with a PSA for tickets, QuickBooks for the ledger and a billing spreadsheet that bridges the two. The spreadsheet holds the real logic: seat counts per client, the price each was promised, which licenses renew in which month and the adjustments a technician mentioned in passing. When the person who maintains it is away, invoices wait.

Before choosing anything new, I move that logic into documents the business owns: a price book, an agreement register and a renewal calendar. Then the decision gets clearer. Some firms only need their PSA's own billing switched on properly and a cleaner sync to accounting. Others need an ERP that holds agreements, purchasing and recurring revenue, with the PSA feeding approved time and the RMM feeding device counts. A few are ready for one platform with its own helpdesk.

Migration covers active agreements with pricing and renewal dates, current seat and device counts, prepaid hour balances, open receivables and deferred revenue from annual prepayments. Historical tickets usually stay in the old system. The data migration plan ends with a reconciliation of the first recurring billing run against the spreadsheet it replaces. The general IT services ERP page lists the full module set, Zoho Desk in the US covers the service desk side, and the USA overview explains how remote engagements run.