Purpose and prerequisites
The purpose of this article is to describe EAC Money, the books application we run for ourselves, and to state when we would build the same class of system for a customer. The company names, customers, and dollar amounts in the pictures are made up. The product behavior is real. We are not selling a shrink-wrapped competitor to QuickBooks. We are showing what a purpose-built replacement looks like, and when we would build that class of system for a customer who is fighting a package that was never written for how they sell. How this cycle of the work was delivered — owner as customer, Grok Build as implementer, four days to a checked migration — is a separate piece: Four days to a production ERP. The remainder of this article is about the shape of the books, not about the delivery tool.
The problem packaged tools did not solve
Microsoft Small Business Accounting 2009 was our daily books, and that product ended. The replacements on the table were familiar, and each failed a different requirement. QuickBooks Desktop or Online is an excellent default for a simple cash or accrual shop, and it is weak when two legal entities, a distributor invoice feed, cash-basis posting that must not invent accounts receivable, and a customer portal that is not a QuickBooks Online add-on maze are all required. Made2Manage and other mid-market manufacturing ERPs are the right shape if the firm has a plant, bills of materials, and a shop floor, and the wrong shape if the firm sells labor, Microsoft 365 seats, and the occasional firewall and does not have an MRP problem. A project to “make QuickBooks work” with import rules, extra items, a sidebar spreadsheet, and someone who knows the workarounds turns that person into the system. We sell technology services. We invoice customers, we pay vendors including a distributor, we collect sales tax in some states, we print checks, and we need the same invoice to be readable as a PDF and in a customer login. We do not need job-cost manufacturing, bank-feed theater, or a chart of accounts designed for a florist. Those requirements are why a package became the job instead of the books.
What we built instead
EAC Money is a cash-basis, multi-company web application. Staff sign in with Microsoft Entra ID. The ledger does not move until cash moves: sending an invoice does not create a receivable account; receiving the payment credits income, and tax when tax was on the invoice. That posting rule matches how we already thought about the business, and it is the opposite of smuggling accrual into a cash firm because the package insisted. Two companies can sit in one deployment with separate books. A user receives a role — administrator, bookkeeper, invoicing, or reviewer. The same person can work in business books and, separately, personal cash books. None of that required a second QuickBooks file and a hope that the item lists would stay aligned. The home screen below is sample data. The behavior — cash on hand, open invoices, open bills, recent documents — is the real product.
Figure 1. Home: cash on hand, open invoices, open bills, and recent documents for a sample company. Sample company, customers, and amounts are fictional and do not reflect live books.
Invoices that look like the work
Invoice lines can be labor, hardware with a manufacturer SKU, a section heading, and hours pulled from time entry. Tax groups follow the customer, in-state or out of state. PDFs match what the customer sees in the portal. Payments apply to invoices and, when tax is involved, the cash split knows the tax piece without a side spreadsheet. Distributor billing is not a CSV hobby. When we buy through TD Synnex StreamOne Stellr, Money can pull the reseller invoice, turn it into a customer invoice and a vendor bill, and keep the Synnex order number on both. Packaged small-business accounting treats that hinge as a custom integration in phase two. In this application it is how we actually get paid and how we actually owe the distributor. The invoice detail below uses fictional amounts. The line types and tax behavior are the real design.
Figure 2. Invoice detail for a fictional customer. Description, quantities, and totals are sample data. Sample company, customers, and amounts are fictional and do not reflect live books.
Customers should not need to email for a PDF
The public site at eacpartners.com is a marketing site and, for granted contacts, a read-only portal: invoices, PDF view and download, billed time, and current subscriptions. Access is granted by email, matching the customer’s domain. The general ledger is not opened to the internet. The portal never writes the books. A customer who can retrieve an invoice without waiting for a staff mailbox is the ordinary case this portal is for. A customer who needs to post a payment into our ledger is not a portal user; that posting remains staff work. The list below is the same fictional customer, without staff navigation.
Figure 3. Customer portal invoice list — the same fictional customer, without staff navigation. Sample company, customers, and amounts are fictional and do not reflect live books.
What else sits in the same application
The same application holds bills, vendors, and check printing against the stock we actually put in the printer; sales-tax groups, collection as cash comes in, and a payment to the state; employees, hours, and, when we want it, Teams as the place staff already are; a journal, a chart of accounts, and cash reports, because cash-basis still has a ledger; and inventory quantity when we hold a box, without pretending inventory is the business. If a feature is not how we run, it is not in the product. That omission is the advantage of writing the books for one operator. It is also the constraint: this is not a marketplace application with thousands of checkboxes. A purpose-built system is allowed to be incomplete relative to a package. It is not allowed to be wrong about how this firm posts cash.
When a firm should stay on QuickBooks
A firm should stay on QuickBooks, or move to it, when several ordinary conditions hold. One company, straightforward items, a bank feed that is actually reconciled, and an accountant who lives in that file are the default case QuickBooks serves well. Payroll, inventory manufacturing, or job costing that a specialist package already does well are reasons to stay with that specialist rather than to rebuild it. A purpose-built application also requires an owner; if nobody on staff can own the system, even with us on the hook, software without an owner becomes folklore. Made2Manage, Infor SyteLine, or another plant ERP remains the answer when the firm has a floor, a bill of materials, and scheduling. We should not be hired to rebuild that in a hurry because the user interface looks dated. That is a different project, with a different risk. Packaged tools remain the correct spend when they match the business. They are the wrong spend when the business has been bent to match the package.
When a purpose-built application is the better spend
A conversation about a purpose-built application is warranted when several of the following are true. The package is a pile of memorized workarounds, and the workaround person is tired or leaving. The firm has two or more entities, or a distributor or vendor feed, that the package can represent only as another company file. Customers or technicians need a narrow window into invoices or tickets, not a full accounting seat. The firm is cash-basis, or something equally specific, and the software keeps shoving accrual or accounts receivable at it. The firm already runs Microsoft 365 and wants sign-in, mail, and Teams to be the same identity as the books. Those conditions, taken together, are when the package has become the job. EAC Money exists because we were the customer for that job. The offer is not that a customer should buy Money. The offer is that if the books, the shop, or the customer portal are the wrong shape for QuickBooks, Made2Manage, or the last thing a vendor demonstrated, we will say so plainly, and if a purpose-built application is justified, we will build that application so operators can run the business instead of the workarounds.
EAC Money exists because we were the customer. The offer to another firm is not a shrink-wrapped competitor to QuickBooks. The offer is a plain answer: training problem, package problem, or a build. If it is a build, the operators should run the business rather than the workarounds.
Organizations that want that conversation may contact EAC Partners and bring the three screens they hate most. We will say whether those screens are a training problem, a package problem, or a build.