When IT Can't Integrate Your ERP, You End Up in VLOOKUP Hell

Six months ago your sustainability lead raised a ticket with IT. The ask was reasonable. Pipe activity data out of the ERP (SAP, Oracle, Dynamics, MYOB, Xero, whatever the finance team runs on) and into the carbon reporting tool, so fuel purchases, electricity invoices, freight movements, and supplier spend flow through automatically. IT said yes. They meant yes.

Then a zero-day patch cycle landed. Then the Azure migration hit a snag. Then finance wanted a dashboard for the board pack. Then a security incident ate two weeks. By the time your ticket made it back to the top of the board, a new quarter had started, and the priorities had shifted again.

So what you actually get every month is a CSV export. Twelve thousand rows. Fuel dockets, electricity invoices, supplier PO lines, freight consignments, concrete deliveries, AdBlue top-ups. And now the real work begins.

The VLOOKUP reality nobody talks about

The CSV hits your inbox on the first working day of the month. The next week of your sustainability team's life is effectively this: opening that CSV in Excel, building a lookup table of materials, running VLOOKUP or INDEX/MATCH (or Power Query if someone's brave and has the time) against the NGA Factors library, reconciling aliases, fixing unit mismatches, and dropping the results into a monthly workbook the auditor will eventually pick apart.

There are four diesel spellings in your data. "DIESEL - B5". "Diesel Fuel". "DSL". "Auto Diesel". Three concrete mixes that all mean 32 MPa but were entered differently by three different depots. Eight electricity retailers whose invoice line items describe the same kWh charge in eight ways. A freight provider who reports in tonne-km on one line and in AUD on the next.

And you've got one week to map all of it to the right factor before the month closes.

That is VLOOKUP hell. It is where carbon reporting quietly breaks in most Australian mid-market and enterprise organisations in 2026. Not at the strategy layer. Not in the board pack. In the lookup table.

IT is not the problem. IT is constrained.

Before we go further, let's be clear about something. IT teams are usually the hero of this story, not the villain. The typical Australian mid-market IT team is running a security programme, maintaining two or three core business systems, fielding help-desk tickets, managing identity and access, planning a cloud migration or a consolidation project, and responding to the occasional incident that sets everything else back a fortnight.

Integration projects take time. Real ERP integration, with proper data contracts, error handling, and monitoring, is a multi-month engagement even when the ERP is cooperative. An SAP connector that handles master data sync and transactional flow is not a weekend job. Oracle Fusion costs you architecture review time before you write a line of code. Dynamics and MYOB each have their own quirks. Xero is friendlier but still needs mapping logic somewhere.

So when IT says "six months", they mean six months. And when the sustainability lead comes back two months later to ask where it sits, IT isn't lying when they say "next quarter". That's the queue. The queue is real.

Meanwhile, AASB S2 doesn't care about your backlog. Neither does NGER. Neither does the auditor.

Three silent costs of running carbon on VLOOKUP

The VLOOKUP workflow doesn't fail loudly. It fails quietly, in three ways we see repeatedly.

Alias drift. A new supplier comes online. They describe diesel as "B5 ULSD". Your lookup table has "Diesel - B5" but not "B5 ULSD". The VLOOKUP returns #N/A, someone manually maps it once, and then the manual mapping doesn't make it back into the master workbook because the master workbook lives on someone else's laptop. Next month it's #N/A again. Or worse, someone fixes it silently and the fix isn't documented anywhere.

Unit drift. The NGA factor for diesel is per litre. Someone enters kL on a fuel receipt because that's how the supplier reported it. The VLOOKUP doesn't care about units. It just multiplies. You're now off by a factor of a thousand on that line and nobody notices until a curious analyst spot-checks a number during audit prep. We wrote about this pattern in depth in unit conversion errors in carbon accounting.

Factor version drift. The NGA factors update every year. Your VLOOKUP table doesn't, unless someone remembers to rebuild it. Groups 1 and 2 reporters are finding this the hard way during first-year assurance, when the auditor asks which edition of the factors was applied to each line and the answer is "good question, let me check". Silent factor drift is one of the most common findings we see in NGER audit error patterns.

Any one of these produces a wrong emissions number. Not by a small amount. A unit mismatch on a fuel line can be three orders of magnitude. An alias miss on a high-volume material can shift a facility total by 15% or more. And the VLOOKUP doesn't tell you it got it wrong. It just tells you the answer.

What integration looks like when it's on your timeline, not IT's

Here's the shift we want to suggest. Integration is a spectrum. On one end is a fully engineered ERP connector with bidirectional sync and real-time webhooks. On the other end is someone emailing a PDF. Most sustainability teams think they need the first and end up stuck at the second, because the middle of the spectrum doesn't get discussed enough.

The middle looks like this. Drop your ERP export in a OneDrive or SharePoint folder that's been configured for your carbon project. Forward the monthly report to a per-project email address. Upload the file in the UI. Post it to a webhook. Pull it in from an API on the schedule that suits you.

Each of those is integration. None of them requires IT to touch the ERP. None of them requires a six-month engagement. The file can be a CSV straight out of the ERP in whatever format the ERP emits. Carbonly reads it natively, alongside PDFs, Excel workbooks, Word docs, and images. The folder sync pattern for OneDrive and SharePoint is how most of our customers start, because it uses infrastructure they already have and permissions IT has already granted.

When IT does eventually land the proper ERP integration, that's also fine. The API and webhook layer is there and waiting. You're not locked into the file-based flow. You're just not blocked by the backlog either.

How factor matching works without a VLOOKUP table

Once the CSV is inside, the matching problem is the real one. This is where the difference between a carbon tool and a carbon system shows up.

Carbonly runs intelligent matching across three layers. The NGA 2025 library is seeded (193 emission factors, 21 of them per-litre fuel factors covering the grades that actually show up on Australian fuel dockets). Your tenant library holds custom factors for materials that aren't in NGA, which matters enormously in construction where material diversity is the pain point (concrete mixes, aggregates, steel grades, hired plant, AdBlue). EPD imports bring product-specific factors for materials where the supplier has published one. Five-tier material matching resolves supplier naming variants to the right factor with confidence scoring on every line.

Activity-based matching is preferred wherever the source document supports it. Litres, kWh, tonne-km, tonnes, FTE. Spend-based is available when activity data genuinely isn't there, but the core differentiator of the platform is that it reads physical quantities off the supplier's own invoice. Most carbon tools default to spend-based because they can't extract quantities from source documents. That's a real distinction, and it's the one auditors are pushing back on for Scope 3.

When a new supplier naming variant shows up, the system learns. Confirm "B5 ULSD" maps to diesel once, and common variants roll through on subsequent passes. A Trust Graduation Agent tracks per-material confirmation counts and graduates high-confidence mappings to auto-confirm so your team isn't re-approving the same lookup every month. A Data Health Agent watches the CSV as it lands and flags outliers, missing mappings, and factor gaps proactively rather than leaving them for the auditor to find.

None of that is something a VLOOKUP can do. Not because VLOOKUP is a bad formula, but because a formula is not an agent. It doesn't learn. It doesn't flag. It doesn't remember.

Why this matters for Scope 3 under AASB S2

The activity-data problem is acute for Scope 3. A CSV from a freight provider is where tonne-km actually lives. A CSV from your electricity retailer carries the kWh and the site. A supplier invoice for concrete tells you the cubic metres delivered and the strength grade. If your workflow can't read that CSV into emission records with provenance, you fall back to spend-based proxies, and AASB S2 assurance is getting stricter about spend-based substitutes for categories where physical activity data was available.

NGER reporters hit this too, but NGER is more permissive on data sources than ASRS. Remember NGER uses AR5 GWP values and AASB S2 uses AR6, so your methane and N2O factors are not interchangeable between the two submissions even though they use the same underlying activity data. The emission factor versioning problem is one of the many things a static VLOOKUP table won't handle.

Every emissions record in Carbonly links back to the source document. The CSV you uploaded. The PDF it came from. The email it was forwarded through. That provenance chain is what an auditor wants when they ask "show me where this 842 kilolitres came from". The answer shouldn't be "a row in someone's workbook".

What to send us on day one

If this is your month, and you're staring at a CSV wondering how much of next week you're about to lose, send us three things.

A sample CSV export from your ERP, exactly as it comes out (no pre-cleaning). A list of your sites or projects. A list of the supplier and material names you see repeatedly (the ones that currently break your lookup table). That's enough for us to stand up a project, wire the folder sync or email ingestion, and put the first month's data through the matching pipeline without waiting on IT.

We're currently working with a Tier 1 Australian construction company who started at a single site for exactly this reason, putting real ERP exports through the CSV-to-factor pipeline before scaling across their portfolio. The work is less about the volume and more about getting the material library, alias learning, and factor version control right the first time so the rest of the sites fall in line.

We're not saying this removes the need for real ERP integration eventually. It doesn't. When IT has the bandwidth, the API, webhooks, and MCP connector are there to take advantage of. What we are saying is that your carbon reporting shouldn't sit on the IT backlog waiting for capacity. It can run on the infrastructure your team already uses every day, and the clerical hours your sustainability team is currently burning on VLOOKUP can go back to analysis, supplier engagement, and the reduction work that actually moves the emissions number.

Pricing is per-project by size (Small, Medium, Large, Enterprise) with a $100 per month minimum workspace fee. We allocate the project tier based on what you're actually moving through the system. If you want to talk through what your CSV looks like and whether this fits, email us at hello@carbonly.ai.