Data integration for reporting means copying data from each of a company's systems into one place on a schedule. The data is then matched, so that a customer, a product or an invoice is recognised as the same thing wherever it came from. It is not system integration, which wires applications into each other so they exchange transactions. 110 Analytics, a data analytics consultancy in Malta, does the first and not the second.
You will recognise this
If any of these sound like your office, the rest of this page is about what to do next.
- Every system has its own version of the customer list.
- We export to Excel and line the files up with lookups.
- Our product codes are different in the tills and in the accounts.
- Nobody can tell me which customers are actually profitable.
- The only person who knows how the files join up is on leave.
- We have a spreadsheet that exists only to connect two other systems.
- Every new report means a request to our software supplier.
Why the data in your systems never meets
Each system you run was bought to do one job, and none was built to answer a question that crosses two of them. The accounting system keeps the ledger, the CRM manages the pipeline and the till takes the sale. Each probably does its own job well.
Which customers are profitable once credit notes are counted? Which campaigns bring in sales that finance actually invoices? Each answer needs data from more than one system, and the systems were often set up by different suppliers who named things their own way.
So the joining happens by hand. Someone exports each system into Excel, lines the files up and fixes the rows that do not match. The figure that comes out is accepted because nobody else knows how it was made, and it works until that person is on leave.
Data integration is not system integration
Data integration for reporting copies data out of your systems into one warehouse, where it is matched and reported on. System integration connects applications to each other, so that an order in one creates an invoice in the other.
Both are called integration, but they are different jobs. System integration, often built with middleware, is valuable work and it is not what we do.
We do not connect your applications to each other, we do not build middleware, and we do not write data back into your business systems. If you need orders to flow from your e-commerce site into your accounting system, your software supplier or a system integrator is the right call.
We do the reporting side, and your systems stay exactly as they are. We read their data on a schedule, bring it into a warehouse built in your environment under your account, and apply one agreed definition to every term. The dashboards, the automated reports and the AI layer all read from that one place.
Which systems get connected?
We connect the systems your reporting depends on, and the list is usually longer than anyone has written down. These are the types we connect; the data audit lists yours.
Accounting and ERP
Invoices, credit notes, payments, costs and the ledger. The anchor for every financial figure.
CRM and sales tools
Leads, pipeline and accounts, matched to what finance invoiced, so sales and finance report the same customers.
POS, booking and e-commerce
Orders, bookings and returns from the systems that take money from customers, by outlet and by channel.
Operations and stock
Projects, stock movements, deliveries and timesheets: whatever the business runs on day to day.
Advertising and web analytics
What Google Ads, Google Analytics and your other channels report, joined to the leads and sales that followed wherever your systems record the link.
Spreadsheets
The budget, the price list, the mapping files and the side trackers.
Every source, one warehouse
How does an overnight load work?
An overnight load is a scheduled job that reads new and changed data from each system after working hours and copies it into the warehouse. It reads. It changes nothing in the source system, and it is scheduled for the quietest hours.
How each system is reached depends on what it offers. It might be an API, which is a documented way for another program to ask for data. It might be a read-only database connection, a standard connector where one exists, or, failing those, a scheduled export into a shared folder.
We choose the least intrusive route each system allows, and ask for read-only access wherever it can be granted.
The warehouse also keeps history that source systems overwrite. When a product moves category, the source shows only today's version; the warehouse can keep yesterday's too, so last year's figures still add up.
When leadership opens the dashboard in the morning, the numbers are current to yesterday. If a load fails, a rule raises a flag so it is fixed before anyone relies on the numbers. Your operations do not depend on the warehouse, so nothing else stops.
Matching customers, products and invoices across systems
Matching the data is the hard half of integration; copying it is the easy half. Your CRM knows a customer by an account name, your accounting system by a customer code, your e-commerce platform by an email address. A product has one code in the tills and another in the ledger.
Until those are matched, nothing can be joined. So during the build we work through each list that matters (customers, products, suppliers, outlets, invoices). We agree with your team how a record in one system is recognised in another.
Sometimes a shared code already exists. Sometimes the rule is a combination, such as account code plus billing email. Sometimes a mapping table is needed, and someone in your team owns it.
The rules live in the warehouse, written down, rather than in somebody's head or a lookup formula. Records that match no rule are listed, not dropped quietly, so someone can correct them in the system where the error started.
Matching also forces the question of what a customer is: a person, a company or a billing account. We agree the answer with your team once, and every report inherits it.
Three systems, one customer
What about the spreadsheets people keep on the side?
The spreadsheets people keep on the side come into the warehouse too. They can hold some of the most important numbers in the business: the budget, the targets, the commission rules, the list that says which outlet belongs to which region.
There are two kinds. The first holds information no system has, such as the budget. Those become proper sources: one agreed file, in one agreed place, with a named owner, loaded on the same schedule as everything else.
The second kind exists only to stitch two systems together: an export pasted beside another export, with a column of lookups between them. Those are what the warehouse replaces.
Nobody is asked to give up Excel. What stops is the copying and pasting that turned each file into its own version of the truth.
ETL, explained plainly
ETL stands for extract, transform, load. It is the plumbing that moves data from your systems into a warehouse.
Extract means reading the data out of each source, through an API, a database connection or an export. Transform means cleaning it and making it consistent: fixing formats, matching customers and products across systems, and applying your agreed definitions of revenue, margin or an active customer. Load means writing the result into the warehouse, where reports can read it.
You will also see ELT: the same steps, with the transform done inside the warehouse after the load. For a business owner, that is a technical choice, not a commercial one.
Extract and load are mostly routine. The value is in the transform, where your business's own rules are written into the system. A pipeline that moves data perfectly but applies no agreed definitions just delivers the old argument faster.
What data integration changes, in practice
A group running several outlets in Malta sells through a till system in each outlet and an e-commerce site. It keeps its ledger in an accounting system and runs a CRM for trade customers. Product codes differ between the tills and the ledger, and one person maintains the spreadsheet that maps one to the other.
- Margin by outlet is worked out by hand from three exports and the mapping spreadsheet.
- Trade customers appear under different names in the CRM and the ledger, so nobody can say which are growing.
- When the person who keeps the mapping file is away, the figures wait for them.
- A question from the owner about one product line takes a week to answer.
- Every system loads overnight into a warehouse in the group's own account.
- The product mapping is an agreed table in the warehouse with a named owner, and unmatched codes are listed each morning.
- Trade customers are matched across the CRM and the ledger, so growth by customer is visible.
- The owner's product question takes minutes, because there is one place to look.
None of the systems changed. What changed is that their data now meets every night, and the person who kept the mapping file spends that time on analysis instead.
Three ways to join up your data, compared
There are three ways to join up your data: data integration for reporting, system integration and manual exports.
| Data integration for reporting | System integration | Manual exports | |
|---|---|---|---|
| What it does | Copies data into one warehouse for reporting | Connects applications so they exchange transactions | Someone copies data into a spreadsheet |
| Changes your systems? | No. It reads only | Yes. It writes into them | No |
| When it runs | Overnight, on a schedule | As transactions happen | When someone has time |
| Who it serves | Leadership and reporting | Day-to-day operations | Whoever asked for the file |
| Definitions | Agreed once, applied everywhere | Mapped field by field | Decided by whoever builds it |
| If it fails | A rule raises a flag | Orders or invoices can stop flowing | The report is late or wrong |
| Who does it | 110 Analytics | A system integrator or your supplier | Someone on your team |
What is connected by the end of the first month
Implementation is the first month. Three to four weeks from an accepted quote, this is what is running.
Your agreed sources, connected
Each system named in the quote, loading overnight, read-only wherever the system allows it.
A warehouse in your account
Built in your environment, under your credentials. If we parted company tomorrow it would keep running, and it would still be yours.
Matching rules, written down
How a customer, product or invoice in one system is recognised in another, with a list of the records that match no rule.
Agreed definitions
Revenue, margin, customer and the other terms your reports use, defined once with your team and inherited by every report.
The first live dashboard
Built on the integrated data, with tiered access, so each person sees what they need and nobody sees everything by accident.
How a project starts
- A data strategy callThirty minutes with Glen, free. You leave knowing what your fragmented data is costing you today.
- The data auditAbout three hours with Glen and your team: every system, every side file, and how a number travels from a source to a report. Nothing is installed. It ends with a quote.
- The buildConnections, matching rules, the warehouse and the first dashboard. Your team grants the agreed access, read-only wherever the system allows, and agrees the matching rules with us; we do the building. Three to four weeks from an accepted quote to a live dashboard.
- The fractional teamAn ongoing senior team keeps the loads running and adds the next source as the business changes. Larger projects draw on our partner network, and you still deal with one team.
What we do not do
- We do not build middleware or connect your applications to each other.
- We do not write data back into your business systems.
- We do not replace, migrate or reconfigure your business systems.
- Custody of the data stays with you, in your own account.
- We are not an IT company. Your IT support and software suppliers keep their roles.
Glen Sultana founded 110 Analytics after a career built where the numbers move daily. Our people have run analytics for tier-one companies, S&P 500 firms and high-growth technology businesses. Glen is the person on the first call, and he runs every data audit himself.
- Built in your environment, under your account
- No lock-in: if we part company, it keeps running and stays yours
- Based in Malta
Straight answers
Which systems can you connect?
Business systems whose data can be read through an API, a database connection or a scheduled export. That includes accounting and ERP systems, CRMs, point-of-sale, booking and e-commerce systems, advertising platforms and spreadsheets. The data audit lists yours.
Is data integration the same as system integration?
No. System integration connects applications so they exchange transactions, often through middleware. Data integration for reporting copies data from each system into a warehouse, where it is matched and reported on. 110 Analytics does data integration and does not build middleware.
Will the loads slow down our systems?
The loads are scheduled outside your busiest hours and only read data, so they are designed to stay out of your team's way.
Do you need admin access to our systems?
We ask for the least access each system allows, read-only wherever it can be granted, and only what you agree to. Sometimes your administrator creates that access for us.
Why overnight rather than real time?
Management reporting is about trends, margins and positions, which rarely need to be current to the minute. Overnight loads keep the work off your systems during the day.
What happens to our spreadsheets?
Spreadsheets that hold real information, such as the budget, become proper sources with a named owner. Spreadsheets that exist only to stitch two systems together are replaced by the warehouse. Nobody is asked to stop using Excel.
What does data integration cost?
The work is quoted at the end of the data audit, because the figure depends on how many systems you run and how much matching they need. The warehouse sits in your own account, so the provider bills its running costs to you directly.
Why not ask our software supplier or ERP partner to do it?
Your supplier knows its own system and should keep looking after it. Reporting across the business needs every system's data matched under definitions your team agrees, and that job sits outside any single system. We do that part, read from all of them, and replace none.
Who owns the data and the warehouse?
You do: every load runs into a warehouse in your own account, and our data warehouse page explains how that works.
Terms you will meet
- API
- A documented way for one program to request data from another. The usual route for reading data out of a modern system.
- Master data
- The core lists every system holds in some form: customers, products, suppliers, locations. Matching them is a large part of the work.
- Ontology
- The written list of your business's own terms, each with one agreed definition, mapped to where its data lives.
- Middleware
- Software that sits between applications and passes transactions from one to another. It belongs to system integration, and we do not build it.