What a FileMaker-Based ERP Should Cover for a Manufacturer

A FileMaker ERP for a manufacturer should cover seven connected jobs: quoting, orders, inventory, work orders, purchasing, shipping, and job costing, all reading from one shared record. You build them in stages, but you plan for all seven from the start. Everything else can wait until those seven run cleanly, and accounting can stay in the package you already use.

Here is a Tuesday morning we hear about often. A customer calls the operations manager asking when their order ships. She checks the order spreadsheet, walks to the floor to ask the lead which step the job is on, then emails purchasing to find out if the bar stock arrived. Three sources, three answers, and none of them agree with the whiteboard.

An ERP (enterprise resource planning system, software that ties sales, production, inventory, and purchasing into one record) exists to fix exactly that. The question is what yours needs to do.

Scope the FileMaker ERP around how your shop runs

Packaged ERP systems are built to cover every kind of manufacturer. That can leave you configuring around screens you never use while the workflow that makes your shop different stays in a side spreadsheet. A custom build starts from how work actually moves through your building. We have written about building a custom ERP around manufacturing workflows; this post is the scope checklist.

The seven modules that carry the day

Each module hands its data to the next. Miss a link and someone rekeys it.

• Quoting. Material, setup, run time, outside processing, and margin in a repeatable model. An accepted quote becomes the order without retyping.
• Orders. One record per customer order with part, revision, quantity, promise date, and status. This is where the “when does it ship” question gets answered.
• Inventory. On hand, allocated, and on order for each item, with every receipt, issue, and adjustment logged so the count on screen matches the shelf.
• Work orders. The job traveler in digital form: operations, routing, materials to pull, and who completed each step. This is also where WIP (work in process, jobs started but not finished) becomes visible.
• Purchasing. Purchase orders tied to the jobs or stock levels that triggered them, with expected dates feeding order promise dates.
• Shipping. Pick, pack, and ship against the order, with tracking on the same record customer service reads.
• Job costing. Estimated versus actual material, labor, and outside services per job, so the next quote learns from the last one.

Why does one source of truth matter more than any single module?

Now the same Tuesday, after the build. The operations manager opens the order. She sees the work order is at deburr, the bar stock has arrived, and the ship date still holds. One screen, one answer.

That only works because the modules share records instead of passing files:

Quote accepted

↓

Order created with the quoted part and price

↓

Work order generated, materials allocated

↓

Shortages raise a purchase order

↓

Job completes, shipment recorded

↓

Actual costs roll up against the original quote

The integration between your ERP and CRM follows the same rule. Customer data lives in one place and every module reads it from there.

What can wait until phase two?

Reasonable candidates for the roadmap rather than the first release:

• MRP (material requirements planning, automated forecasting of what to buy and when) until you trust your inventory counts.
• Finite scheduling (planning jobs around real machine and shift capacity), once work orders are reliably tracked.
• Quality and nonconformance tracking, unless a customer or certification requires it now.
• Portals and dashboards beyond the few reports you check daily.

These all depend on clean data from the core seven, and they are far easier to build once that data exists.

Build first where money leaks today

A staged build usually works better than a big-bang cutover (switching everything over on one date): each stage proves itself before the next begins, and your team learns the system a piece at a time. Let the money set the order.

• If jobs regularly lose margin and nobody knows why until month end, start with quoting and job costing.
• If customers call to ask where their order is, start with orders and work orders.
• If you expedite material or find stock you already owned, start with inventory and purchasing.

Pick the costliest leak, run that module for a few weeks, then connect the next. Our earlier piece on why FileMaker is an inexpensive alternative to packaged ERPs covers the cost side of that choice.

Where does accounting fit?

Keep it where it is. Your bookkeeper knows QuickBooks (or whatever you run), your accountant reviews it, and rebuilding a general ledger adds risk without adding value. The ERP handles operations, the accounting package handles the books, and an integration carries customers, invoices, and vendor bills between them so nobody types an invoice twice. Claris documents a QuickBooks connector in Claris Connect, its integration service, with actions such as creating customers, invoices, and purchase orders. Plug-ins and direct API connections are other options, and the right one depends on which edition of QuickBooks you run.

Kyo Logic builds custom Claris/FileMaker and manufacturing software for New England companies. We scope FileMaker ERP builds module by module, starting with the one that is costing you the most today.

Frequently asked questions

Can FileMaker be used as an ERP for a manufacturing company?

Yes. FileMaker can run quoting, orders, inventory, work orders, purchasing, shipping, and job costing in one connected system. It is one option among several; the bigger decision is scoping around how your shop works.

Do we have to replace QuickBooks to use a FileMaker ERP?

No. Accounting can stay in the package you already use, and an integration connects the two so customers, invoices, and bills are not entered twice.

How long does it take to get the first module running?

It depends on the module and how clean your existing data is. A staged approach puts one module into daily use before the next begins.

If you want a second set of eyes on where your data is breaking down, book the free 20-minute Data Health Check.