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

If IT can't build your ERP integration this year, you can still get every line of the monthly CSV matched to the right emission factor and traced back to the file it came from. Drop the export, exactly as the ERP emits it, into a OneDrive or SharePoint folder or a per-project email address. The week of VLOOKUP against the NGA library goes away, and IT doesn't have to touch the ERP.

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.

Where your month-end week actually goes

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.

Why the ERP integration keeps slipping to next quarter

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 ways a VLOOKUP gives you a wrong number without telling you

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

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. Group 1 and 2 reporters can find 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 common 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.

How to get ERP data in this month without waiting on IT

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 the 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, exactly as the ERP emits it. Carbonly reads CSV natively, alongside PDFs, Excel workbooks, Word docs, and images, eight file formats in all. The folder sync pattern for OneDrive and SharePoint is the natural starting point for most teams, 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.

Every line matched to the right factor, without a lookup 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.

What you get is "B5 ULSD", "DSL" and "Auto Diesel" all landing on the right diesel factor, with a confidence score on every line. Carbonly gets there by 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. Many carbon tools default to spend-based, because extracting quantities from source documents is hard. That's a real distinction, and it's the one assurance providers are increasingly probing for Scope 3.

When a new supplier naming variant shows up and a reviewer corrects the match or assigns "B5 ULSD" to diesel, that wording is saved as an alias for your organisation, and later lines with the same wording match through it, so your team isn't re-mapping the same lookup every month. A Data Health Agent checks scope and month coverage, incomplete records and stale data, and the anomaly checks flag outliers, so gaps surface before the auditor finds them.

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.

Scope 3 figures your AASB S2 assurer can trace

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 providers are likely to question spend-based substitutes for categories where physical activity data was available.

NGER reporters hit this too. 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, you can have that month's data matched to factors without waiting on IT. It takes 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.

The sensible pattern for a Tier 1 Australian construction company is to start at a single site for exactly this reason, putting real ERP exports through the CSV-to-factor pipeline before scaling across the 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 ChatGPT or Claude integration 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, sized to what you're actually moving through the system, with a $100 per month minimum workspace fee and no per-seat fees. If you want to talk through what your CSV looks like and whether this fits, email us at hello@carbonly.ai.