To build an internal system from scattered Excel files: inventory the files and who owns each, identify the entities they share (customers, projects, suppliers, items) and give each a unique ID, write a short requirements document that sets the modules and roles, then build one module at a time starting with master data. In Fanann you can put the linked sheets in one .xlsx file and upload it so each becomes a table with its screens, or start with the Product Owner, Noura, to write the requirements and hand them to the builder.
- how to build an internal system for a company
- combine multiple excel files into one system
- internal tool from spreadsheets
- small business management system instead of excel
- how do I connect purchases and projects in one system
- erp alternative for small companies
What is an internal system, and do I need one?
An internal system is the software your customers never see: where your team records projects, orders, purchases and expenses, and where you open one dashboard to know how the company stands. Many small companies already have this system, spread across Excel files: projects with the operations manager, purchases with the accountant, suppliers in someone's inbox, and petty cash in a notebook.
IllustrationPick the one that sounds like you to see the advice.
You do not need an internal-system project. Convert that one file as in turn an Excel sheet into a system, then decide.
This guide is for you. You will build a system of modules around your files, one at a time.
Evaluate an ERP or accounting product first. Build only what it does not cover: the operations that are specific to you.
Start with the inventory in the next section. One hour is enough for the picture to clear.
The build-or-buy trade-off is covered in internal tools or SaaS.
How do I inventory the company's files before building?
Gather everyone who owns a working file and open one table (yes, in Excel) with these columns. An example from a fit-out contractor:
| File | Owner | Who enters | Rows | Pain |
|---|---|---|---|---|
| Projects and contracts | Operations manager | Two people | About 140 | Multiple copies, no update date |
| Purchase orders | Accountant | 3 engineers via WhatsApp | About 2,000 | Approvals lost in chats |
| Suppliers | Procurement | One person | About 90 | Duplicated inside the PO file |
| Petty cash and expenses | Accountant | Site supervisors | About 3,500 | Paper receipts, late entry |
| Labor attendance | HR | Site supervisors | A sheet per month | Not linked to a project |
At the end you will usually find that two or three files carry most of the pain. That is your starting point. The rest can wait.
How do I link the files to each other?
This is the real difference between a set of files and a system. In a system a supplier is written once in the suppliers table, and every purchase order points to it by number. In files the name is typed into every row, so it becomes Gulf Paints Est., Gulf Paint and Gulf. Split your data into two kinds:
| Kind | Examples | Character |
|---|---|---|
| Master data | Customers, suppliers, items, staff, projects | Changes rarely, and everything else points to it |
| Transactions | Purchase orders, expenses, attendance, invoices | Grow daily, and every row points to master data |
- 1Give each master entity a unique number
A project number, a supplier number, an item code. A simple running number is enough.
- 2Replace names with numbers in transaction files
In the PO file add Supplier number and Project number columns next to the name, then unify.
- 3Put linked sheets in one file
A suppliers sheet, a projects sheet and a purchase orders sheet in one .xlsx file. On upload, a column in one sheet can be detected as matching another sheet.
- 4Check the match rate
If some supplier numbers in the orders have no match in the suppliers sheet, those are orphan records to fix now, not after launch.
Do I need a requirements document for a small system?
For one file, no. For a system of several modules, yes, even two pages. Not for bureaucracy: when the accountant, the operations manager and the owner sit together, they discover each means something different by approving a purchase order. Finding that on paper costs minutes. Finding it after the build costs days.
If you have never written one, the Product Owner, Noura in Fanann plays that role: she asks the questions that settle scope, writes the requirements document and task list, revises a selected part on request, then hands it to the builder. The minimum the document should hold:
- Modules in order: what is built first and what waits.
- Roles: who they are, and what each sees and does in each module.
- Business rules: a purchase order above 10,000 needs the owner's approval.
- Reports: every question the system must answer without anyone's help.
- Out of scope: what will not be built now, written down.
The method in detail: how to write a requirements document.
In what order should I build the modules?
The rule: foundations before what depends on them, and painful before pretty. For our contractor:
- Week 1Master data
Projects, suppliers and staff. Import, review and merge duplicates. No transactions yet.
- Weeks 2–3Purchase orders
The most painful module: the engineer's request, approval, then delivery status. In real use before moving on.
- Weeks 4–5Petty cash and expenses
The site supervisor logs an expense from a phone with a photo of the receipt, tied to the project.
- Week 6Owner dashboard
Each project's cost from purchases and expenses against contract value. Now there is data to show.
- LaterAttendance and beyond
Added once the earlier modules are stable and the team asks for it.
How do I build it in Fanann: from the file or from a description?
- Your data exists and is tidy in sheets
- You want your rows in the system from the first moment
- The module looks like a table: list, form and report
- You want a ready proposal to adjust
- The module has several steps and approvals
- There is no file and the work is on paper
- You want special screens: an owner dashboard, a supplier portal
- You already have a requirements document
The two meet. Upload the master data file in Excel to App (.xlsx or CSV, up to 10 MB) so each sheet becomes a table with its list, form and detail page plus owner, manager and staff roles, then continue the other modules by describing them in the same conversation, like any app in Fanann. An example for the second module:
Add a Purchase orders module linked to the existing Projects and Suppliers tables. The engineer creates the order: project, supplier, line items (description, quantity, price) and required delivery date. Orders up to SAR 10,000 are approved by the projects manager; above that they also need the owner's approval afterwards. After approval the accountant changes the status to Ordered, then Delivered, attaching a photo of the invoice. An engineer sees only the orders of their projects; the accountant sees all but cannot edit line items after approval. Show the total of approved orders on the project page. Record who approved and when. Show me the plan first.
Try it in FanannWho sees what inside the system?
With files the answer was whoever received the file. In a system you have to decide, and the easiest way is a matrix drawn before the build:
| Module | Owner | Manager | Staff |
|---|---|---|---|
| Projects | Everything, with contract values | Their projects, without margin | Assigned projects only, no amounts |
| Purchase orders | Approves above the limit | Approves up to the limit | Creates and sees their own |
| Suppliers | Everything | Adds and edits | Picks from the list only |
| Expenses | Reports across all projects | Reviews their projects' expenses | Logs their own expenses |
| Users | Adds and removes | Nothing | Nothing |
The three roles come ready when you build from a file, and you ask for the finer rules by describing them. Common mistakes are covered in roles and permissions for a staff app.
How do I keep the system healthy after launch?
For repeated testing after each change, the QA Engineer on paid plans supports scheduled runs. And where a site has no reliable internet, some modules may suit a Windows program with a local database; see desktop app or web app.
A successful internal system is not the one with the most features. It is the one that made the team stop opening the old file.
Key takeaways
- The problem is not the number of files. It is the same customer written five ways in five of them.
- Start with master data (customers, items, staff) before the transactions that depend on it.
- A two-page requirements document prevents rebuilding three times.
- One module the team actually uses beats five half-finished ones.
- If your work is fully standard and accounting-led, an off-the-shelf ERP may be the safer choice.
Frequently asked questions
How do I build an internal system for my company?
What is the difference between an internal system and an ERP?
Can several Excel files be merged into one system?
How long does it take to build an internal system from files?
Who owns the system and the data once it is built?
Do I need an IT employee to run it?
Ask your AI assistant about this
Copy this prompt into the AI assistant you use, then add the details of your own case.
I am reading this guide: “How to build an internal company system from scattered spreadsheets” https://fanann.com/en/blog/build-internal-system-from-spreadsheets/ My question: how to build an internal system for a company Use that page as a source and explain the answer step by step for my situation, tell me what to check before I start, and cite the page link.