Single Source of Truth for a Small Manufacturer: Capture, Connect, Decide, in That Order

Once a month I get on a call with the owner of an organization whose contract with us covers a stack of smaller projects. For a long time, the status of each of those projects lived in a spreadsheet somebody on my team updated by hand before the call. Something on it was always out of date. I’d be telling the client a project was still in progress while half-remembering an email that said it had wrapped, and I’d sound stupid in front of my own customer. The right answer existed all along, sitting in our time tracker and on the client health board we review every week. I just couldn’t sign for the number on my screen.

So we stopped retyping it. Hours now come straight from the time tracking system and project status comes straight from the health board, and the number I read on that call is the one the work produced.

That fix is what a single source of truth looks like at our size, and it had very little to do with buying anything.

A single source of truth is the state where every number your business runs on has one agreed definition, one place it gets created, and one path to the person deciding from it, so two reports asked the same question give the same answer. For a small manufacturer you get there in a fixed order: capture the record cleanly, connect the systems you already own, then decide from the numbers on a schedule. Most of the advice on this topic starts in the middle.

What does a single source of truth mean for a small manufacturer?

It means you can get an answer about your own business that you’d put your name to, in minutes, without anyone rebuilding it in a spreadsheet first. That’s the test I use, and it’s stricter than it sounds.

The glossary definitions that rank for this term, from Integrate.io, Skyvia and Workday, describe storing each piece of data in one central location so everyone uses the same records. A founder-led shop running a CRM, a quoting tool, accounting software and a time tracker isn’t going to move all of that into one place, and it doesn’t need to. What it needs is for each fact to have one home, and for every report and every person to read that fact from its home instead of from a copy.

The symptom is easy to spot. Ask two people, or two reports, the same question about last month and you get two answers. “Every system gives me a different number” is the sentence I hear most, and three different constraints can produce it. Which one is producing it in your building is the diagnosis.

This page is written for founder-led manufacturers running three to eight business systems, with nobody in-house who can connect them, define the rules, or read the output. If that’s you, you’re in good company. Almost every shop I talk to looks like this, and almost none of them got there by doing anything wrong. They bought good tools one at a time as the business grew, and nobody’s job was making them agree.

Is a single source of truth one system?

In a small manufacturer, almost never. It’s an agreement about which system owns which fact, plus the connections that carry each fact from its owner to everything that reads it.

That’s the difference between a source of truth and a system of record, one of the questions Google surfaces most often on this term. IBM draws the line cleanly: a system of record is the authoritative source for one business domain or process, and a source of truth pulls together and reconciles data across them. In shop terms, your accounting package is the system of record for invoices and payments, the CRM for customers and quotes, the project tool for jobs, and the time tracker for hours. Each of those can be correct on its own. The single source of truth is the layer that makes them agree with each other.

Written down, the agreement is a short list with three columns: the fact, the one system that owns it, and who is allowed to change it. Order value, customer, job status, hours, invoice paid. Five to ten rows. Yours will differ from anyone else’s, and filling it in is half the value, because the arguments that surface while you fill it in are the arguments that were quietly producing your two answers.

Other names you’ll see for the same idea: “one version of the truth,” “golden record,” and, used loosely, “system of record.” They all point at the same promise. One question, one answer.

Why “pick a platform” is the wrong second step

Google’s AI Overview for this term gives a three-step recipe for building one: list your sources, pick a platform such as a data warehouse or a master data management system, then set rules about who can change what. The first step is right. The order of the other two is where small manufacturers get hurt.

Buy the platform before anyone agrees what an order value means, and you get three numbers on a nicer screen. The warehouse faithfully collects the order value from your quoting tool (before discount), from your accounting package (after discount, before freight) and from your CRM (with tax and freight), and lines them up beautifully. Nobody can tell you which one is true, because nobody ever decided. The rules were supposed to come first.

I’ll be straight about where I’m coming from. We don’t sell or resell software, and if a vendor ever offers us a commission for recommending them, it comes to you as a credit on your invoice. So I’ve got nothing riding on whether you buy a platform. Most of the time the systems you already paid for are fine, and what’s missing is the agreement and the plumbing between them.

Why does the order matter so much?

Because a fix at the top inherits every problem underneath it, and it inherits them without telling you. Connect two systems that disagree about a record and you’ve automated the disagreement. Build a dashboard on records nobody entered and you’ve built a very clean picture of nothing.

If you’ve read The Goal, you know the idea underneath this. At any moment one thing limits the whole system, and effort spent anywhere else doesn’t move the output. The office works the same way. On our side we’ve mapped it as nine constraints in three tiers, and they break in order. Here it is in short:

• Capture (constraints 1, 2, 3). Is the thing recorded at all, do people agree what it means, and is it entered right the first time?
• Connect (constraints 4, 5, 6). Dead handoffs, shadow spreadsheets, and one person who is the system.
• Decide (constraints 7, 8, 9). Answers that are hand-built and late, no regular meeting where the numbers get read, and tools like BI and AI that were bought and never fed.

The useful thing about the order is that it turns a pile of complaints into a sequence. The constraint worth fixing is the earliest one that’s broken. It’s rarely the one bothering you. Tier 3 failures are loud and Tier 1 failures are invisible, which is exactly backwards from how urgent they are.

Capture: what has to be true before your data is worth connecting?

The record has to exist, it has to mean one thing to everybody, and it has to be entered right the first time. Those are constraints 1, 2 and 3, and every number you’ll ever trust is built on them.

Is the thing being recorded at all?

Constraint 1 is the floor, and the most common version in a shop is time. Are people recording how long they worked, and against which job? Plenty of shops track hours at the employee level for payroll and never against the job. Then somebody asks what a finished job cost, and the honest answer is that nobody knows, because the labor was never written down anywhere it could be added up.

The same thing happens on the sales side. You can’t know your win rate on quotes if nobody goes back and marks the quote won or lost.

Do the people creating the record agree what it means?

Constraint 2 is the one people skip past, and I’d argue it’s the single most common reason two reports disagree. Order value is the example every shop has. Sometimes it’s the discounted number and sometimes it’s gross. Sometimes it includes tax and freight and sometimes it doesn’t. Put two systems side by side where one includes freight and one doesn’t, try to add them up, and you’re answering two different questions at once.

“Booked revenue” is the one I find most revealing, because everyone thinks they know what it means. I know a company whose salespeople earn a commission when a contract is signed. Two months into onboarding, it can become clear the customer isn’t a fit and the work never goes ahead. No revenue ever arrives, and the company has to claw the commission back. Is revenue the day the contract is signed, the day it’s booked, the day it’s paid, or the day the project is delivered? They had been using all four in different places, so their sales numbers and their finance numbers could never agree.

Manufacturers get their own versions. A job’s scope grows halfway through and the order goes up. Does the deal count at the signed value or the new one? On a multi-year order with an option year, do you count the option? And on the cost side: do you spread overhead evenly across every project, or treat it as a fixed cost and keep it out of job margin? Each answer is defensible. What isn’t defensible is two systems using two different ones.

“Qualified lead” and “won job” go the same way. At one company I worked with, somebody hand-built a sales report every week because nobody had ever agreed what a qualified lead was. There was no field anyone could fill in honestly, and nobody did.

The fix is unglamorous. Define what the term means, in a sentence, agreed by the people who create the record and the people who read it, and then enforce it at the point where the record gets created.

Is it entered right the first time?

Constraint 3 is what you get when a record is typed in by hand. Your CRM is only as current as whichever salesperson felt like writing up their call notes, and anything keyed by hand carries a rate of wrong. Dropdowns beat free text for exactly this reason. The fix we use is validation at entry, so bad records stop being born instead of getting cleaned up later.

A five-minute check you can run this week: take one number from your Monday meeting and ask three people what it includes. If you get three answers, you’ve found your starting point, and it’s below anything a new system would touch.

Connect: how do you join the systems you already own?

Give each fact one home, then replace every person who carries a record between systems with a connection, starting with the handoff somebody retypes most often. That’s the Connect tier, constraints 4, 5 and 6, which the data silos guide walks through one gap at a time, and it’s where most owners assume the project starts.

• Dead handoffs (constraint 4). Work jumps from one system to another and a person carries it across. The quote gets written in the quoting tool and somebody re-keys it to run the job. It’s error-prone on its face, and on a busy week it just doesn’t happen. This is usually our first win, because it’s the fastest thing to count and it hands somebody hours back every week.
• Shadow spreadsheets (constraint 5). You bought and implemented the system and your people still do the work in Excel next to it. That spreadsheet is the cheapest answer your people have found to a question the system can’t answer yet.
• One person is the system (constraint 6). Someone runs a report every Friday afternoon and keeps everything working, while nobody else in the building knows how it works. I’ve had that one described to me by people who work with aviation shops. It holds up right until the week she’s out.

What I’d add is the part people skip. Before we connect anything, we check three things, and they’ve saved more money than any integration we’ve built.

Does it need connecting at all? Sometimes the answer you want already lives in one system and nobody knows to look there. Back to my monthly call: the status and hours already sat in our project tool and time tracker, and the fix was to stop retyping them. Every connection you build is a connection somebody has to maintain.

Can you trust what’s underneath? If the time tracker isn’t current, or you can’t tell which hours are billable, connecting it gets you an automated report you still can’t sign for. You’ve just gotten the wrong number faster.

Do the two systems mean the same thing by a record? Every system has its own nouns. One calls them clients, one calls them organizations, one calls them projects. In our own project tool, each client is a space inside a single organization. Map our organization to the wrong object in another system and the connection works perfectly. Records flow, nothing errors, and every one of them lands in the wrong place. Connect the wrong nouns and you’ve built a faster way to make dirty data.

We usually work inside what you already run: QuickBooks, HubSpot, Pipedrive, GoHighLevel and Zoho on the CRM and accounting side, plus the reporting and automation tools around them. We haven’t worked inside an ERP, and I’d rather you hear that from me than assume it. If you run one that exposes an open interface, we can connect to it, and we’d tell you plainly where the work gets harder.

Decide: what do you do with the numbers once you trust them?

Put them in front of the person who decides, on a schedule, early enough to change something. That’s the Decide tier, constraints 7, 8 and 9, and it’s the one owners can usually name on the first call because it’s the only tier with numbers attached.

Hand-built, too-late answers (constraint 7) is month-end as a reconstruction project. Somebody pulls revenue from one system, job completion from another and hours from a time tracker, and stitches them together by hand. By the time the number reaches you, the moment it described is gone. The goal is to move month-end off the export-and-stitch routine and onto numbers the systems already produce.

No cadence (constraint 8) is having the numbers stitched together, live, in a portal nobody opens. There’s no standing meeting where they get read and decided on. If you run EOS you already know the fix: a short scorecard, checked every week, rolled up from the work. What a single source of truth adds is that the scorecard fills itself, from several systems at once, instead of somebody building it Monday morning.

Take qualified leads per week to see what cadence changes. Without it, you know you had a slow month. With it, you know the weekly target, whether you hit it last week, and where it fell short: fewer people reaching the website, fewer referrals from partners, or the salespeople being out that week. Each of those is a different decision. Before, they all looked like “sales was slow.”

Starving tools (constraint 9) is your BI, your automation and your AI, bought and paid for and fed nothing. This is where most AI projects stall right now. A model connected to a CRM full of stale records gives you a faster way to produce a confident wrong answer. We cover why in We Pay for AI and Nobody Uses It and We Won’t Put AI on a Business That Can’t Feed It. Once the tiers underneath hold, AI earns its keep fast, on jobs like drafting a new quote from your last two hundred.

What does a single source of truth look like on one question?

Pick one question you can’t answer today and walk it down the tiers; the work is usually two or three layers below where it started. Take a question almost every owner asks: what was our margin on that job?

1. Decide. You want job margin on the weekly scorecard so you can catch a losing job while it’s still running. Today it shows up at month-end, if at all.
2. Why it’s late. The number is hand-built. Somebody pulls quoted cost from the quoting tool and actual cost from two other places and lines them up in a spreadsheet when they have a free afternoon.
3. Connect. Labor lives in the time tracker and materials live somewhere else, and quoted cost lives somewhere else again. So you connect them, and quoted cost and actual cost land in the same place.
4. Capture. Then you look closer and find the time entries were only ever recorded against the employee, never against the job. There’s nothing to connect. Or time does get logged to jobs, but nobody ever agreed what counts as job time versus general labor, so two people log two different things into the same field.

The owner came in asking for a margin report. The work was three layers down, and no amount of dashboard building was going to surface it. Once the hours are recorded against the job and everybody agrees what job time is, the connection is straightforward and the scorecard number is one you’d sign. With it, you can set up an alert the first time a job crosses its estimate, instead of finding out at month-end when it’s somebody’s variance to explain.

What does a 90-day build leave you with?

One or two fundamental problems fixed, a scorecard that shows how the business is doing without anyone building it by hand, and a ranked list of the next bottleneck to fix. That’s the 90-day build, and it’s how most of our engagements start.

• First two weeks: access. We log in to every system the build touches and read what’s there.
• Month one: interviews with the people who use the systems as well as the people who bought them, because the way a tool gets used drifts once it’s live. Around week four or five we put a draft of how your systems really work in front of your key people and ask them to poke holes in it.
• Month two: the connection work.
• Month three: finishing the build, rewriting the findings, and showing your team how to read what’s now in front of them, plus a backlog of what to fix next.

The guarantee covers the build, because the build is the part we control. Nobody honest can promise you a revenue number. By day 90 the systems and numbers the 90-day plan named are connected, they reconcile, and the report ships. If they don’t, we keep working until they do at no additional cost. The plan is agreed in writing before we start, and it isn’t a promise that every system in your building is connected by day 90.

We also measure the change instead of asserting it. On day one we write down the six questions you most need answered about your own business, whether you can answer each one today, and how long it takes. On day 90 we ask the identical six and write the answers next to the originals. More of them answerable, each one faster.

The work is done by a small team, three of us who work together and can move across your whole stack. Think of a small special-operations team coming in to fix your hardest problems, with a named person inside your systems from the first day.

Where should you start?

Start with one question you can’t answer today, then find out which constraint is in the way. You can do the first part this afternoon. Write down the six questions you most need answered about your business, and next to each one, whether you can answer it and how long it takes. Unknown counts as an answer, and writing it down is the point.

If you’d like help with the second part, this is how it runs with us.

1. A 25-minute call. Five questions about how your systems work today. Nothing to prepare, no access to anything, and you leave with what I think is binding and what I’d fix first.
2. The Systems Snapshot. A short form: where each function lives today, what gets retyped and by whom, and which of your own numbers you can produce. It also becomes your day-0 baseline.
3. The systems audit, $1,200. The form tells us what you believe. Getting into the systems tells us what’s true, and those are frequently different. You leave with a 90-day plan: what’s binding, in what order, and what it takes to fix each one. Implement it yourself, or put us on it and the full $1,200 comes off the $9,000 build. Either way, the plan is yours.
4. The build or the standing order. The 90-day build is $9,000, fixed scope. If you’d rather keep it running, the standing order is $4,250 to $8,150 a month, flat, priced by how many fixes we can have going at once.

A few things we won’t do, in case any of them rules us out. We don’t rip out what you’re running. We don’t sell software. We don’t run AI pilots. And we don’t touch the machines on your floor; we work the back office, where the numbers get made.

If you’ve read this far, you’ve probably got a report that didn’t tie out and it bugged you enough to go looking. That instinct is right. The numbers in your business can agree with each other, and getting there is mostly a matter of doing things in order.