Your Carbon Data Is Already in OneDrive. You're Just Not Using It.

We had a call last month with a property manager running 42 commercial sites across Melbourne and Sydney. She had a system for tracking utility bills. It was, objectively, well-organised. Every site had a folder in SharePoint. Inside each folder: subfolders for electricity, gas, water, waste. Bills arrived as PDFs, got saved to the right spot by accounts payable. Clean. Tidy.

And then, once a quarter, someone spent three weeks downloading those same bills from SharePoint, opening each one, reading the consumption figures, and typing them into a carbon accounting spreadsheet. One thousand-plus documents. Every quarter.

The data was already digital. It was already organised. It was already in the cloud. But the only thing connecting it to the emissions calculation was a person with a second monitor, copy-pasting kWh values from PDFs into cells. That's not a workflow. That's a toll booth between two systems that should be talking to each other.

This is the carbon accounting OneDrive integration problem. And it's far more common than it should be.

The data already exists. The bottleneck is the gap between storage and processing.

A 2025 industry survey found that over 70% of mid-sized Australian businesses use SharePoint for daily document collaboration and storage. Microsoft 365 dominates the enterprise market here — Australia has roughly 29,000 corporate customers on the platform, making it one of the highest per-capita adoption rates globally. If you work in property management, construction, or any multi-site operation, the odds are good that your utility bills already land in OneDrive or SharePoint.

That's the part nobody talks about when they discuss automated emissions data collection. The automation discussion always starts with "how do we get documents into the carbon platform?" But for most organisations, the documents are already sitting in a structured folder somewhere. They've been there for years.

Consider a mid-market property company with 30 sites. Four utility types per site, monthly billing. That's 1,440 documents per year already landing in SharePoint through existing accounts payable processes. Nobody needs to change how bills arrive or where they get saved. The existing process is fine. What's broken is what happens next — or, more accurately, what doesn't happen next.

The GHG Protocol reports that 83% of companies disclosing climate data struggle to access their emissions data. Not calculate it. Access it. And the ANAO found 72% of NGER reports contained errors, most caused by gaps in electricity data and missing sources. These are literally "we had the bill but nobody typed it in" problems.

How Carbonly's OneDrive and SharePoint sync works

We built the integration using Microsoft Graph API because that's the right way to do it. Not screen scraping. Not third-party connectors that break every time Microsoft updates their UI. The actual API, with OAuth2 and PKCE authentication, which is the same enterprise-grade auth pattern that Microsoft recommends for production applications.

Here's the setup. You authenticate Carbonly with your Microsoft 365 tenant. Pick a folder in OneDrive or a document library in SharePoint. Assign it to a business unit or site in Carbonly. Done.

From that point, every new file that appears in that folder gets automatically synced into the Document Hub and queued for processing through the same 7-phase AI pipeline that handles manual uploads and email ingestion. The system tracks what it's already seen using file identifiers and timestamps — it only picks up documents added since the last sync. No duplicates. No reprocessing.

We support 17 file types: PDF, CSV, Excel (.xlsx and .xls), Word (.docx), PowerPoint (.pptx), RTF, and images including PNG, JPEG, WEBP, TIFF, BMP, GIF, and HEIC. That covers everything from standard retailer PDFs to photos of handwritten fuel dockets taken on an iPhone. Files up to 25MB each.

A few technical details that matter for IT teams. The integration uses auto token refresh — it triggers five minutes before token expiry, so the connection never drops mid-sync. Tokens are stored encrypted and never exposed in API responses. And here's the one that comes up in every security review: files are NOT downloaded to Carbonly's servers. They're read in-memory via Microsoft Graph API, processed through our extraction pipeline, and the extracted data is stored. The original files stay in Microsoft's infrastructure. For Australian companies, that means your documents remain in Microsoft's Australian data centres — a data residency question we get asked in almost every enterprise conversation.

Why this matters specifically for property and construction

Property companies are the obvious use case because they already have the folder structure. A typical commercial REIT with 40+ sites has a SharePoint site per building, with utility bill subfolders maintained by building managers or accounts payable. That's exactly the structure Carbonly needs. Point each subfolder at the corresponding business unit. New bills get processed as they arrive.

For a property manager tracking emissions across 50 sites, this turns the quarterly data collection exercise from a three-week manual project into something that happens in the background. No chasing site managers. No downloading hundreds of PDFs. No checking whether Q2's bills have been entered yet. They're processed as soon as they're filed.

Construction companies have a different but equally painful version of this problem. Project drives accumulate fuel dockets, waste manifests, and subcontractor invoices across the life of a build. Our pilot customer generated 10,000 fuel receipts in a single quarter across multiple projects. Those receipts were sitting in project folders in a shared drive. Someone was manually re-entering every one of them.

The integration supports recursive folder traversal up to five levels deep. So a folder structure like Projects > SiteName > FY2026 > Q2 > Fuel works without flattening everything into a single folder.

Mining and remote operations have yet another angle. Sites in remote areas don't always have reliable connectivity. But when fuel dockets and utility records get synced to OneDrive (which happens automatically when devices come back online), those documents flow into Carbonly's pipeline without anyone in the head office needing to do anything. We're not sure this completely solves the remote-site data lag problem — some documents still take weeks to get digitised — but it removes one more manual step from the chain.

What happens after sync

Documents synced from OneDrive enter the exact same processing pipeline as everything else. Classification, vision-to-text extraction, structured data extraction, validation, normalisation, emission factor matching, and audit trail generation. We've written about how that pipeline works in detail elsewhere.

The important point is that the source of the document doesn't change how it gets processed. An Origin electricity bill uploaded manually, forwarded via email ingestion, or synced from SharePoint produces identical output. Same extracted fields. Same confidence scoring. Same emission factor matching via our 5-tier system. Same audit trail linking every calculated number back to the source document.

SHA-256 deduplication ensures that if someone uploads a bill manually AND it also exists in the synced SharePoint folder, it gets processed once. Not twice. This sounds like a minor detail until you're doing NGER calculations and an auditor asks why your Scope 2 figures jumped 15% — because 200 electricity bills got double-counted between two ingestion channels.

Each business unit can have its own OneDrive folder. So you can map Site A's utility folder to Business Unit A, Site B's folder to Business Unit B, and so on. The extracted data stays scoped to the right entity. For companies reporting at the facility level under NGER — where the 25kt CO2-e and 100TJ thresholds are measured per facility — this scoping is how you keep site-level emissions clean without manual sorting.

Three ingestion channels, one pipeline

OneDrive sync is one of three ways documents get into Carbonly. The other two are email ingestion (every project gets a unique email address — forward a bill, it gets processed) and manual upload via the Document Hub. We also have an API for programmatic integration with ERPs and other systems.

They all feed into the same backend. The reason we built three front doors instead of one is that different people in an organisation prefer different channels. The accounts payable team already works in SharePoint — OneDrive sync is their path. The site manager getting a diesel docket in the field — email ingestion from their phone is theirs. The sustainability team doing a one-off historical data load — manual upload makes sense.

The point is eliminating the bottleneck described in that opening story: the person sitting between the document store and the carbon calculation, manually transferring numbers. Doesn't matter which channel removes them from the loop. What matters is that they get removed.

What this doesn't do (yet)

We're going to be honest about the limits.

Google Drive isn't supported yet. We've been asked for it. It's on the roadmap. But our current customer base is overwhelmingly Microsoft 365, so that's where we started. If your organisation runs on Google Workspace, the email ingestion channel and manual upload are your options today.

Folder hygiene matters. If you point Carbonly at a SharePoint folder that contains utility bills mixed with meeting minutes, contract drafts, and someone's holiday photos, those non-utility files will get queued for processing and fail at the classification stage. They won't corrupt your data — the pipeline rejects documents it can't classify as utility or emissions-relevant records. But it creates noise. The solution is straightforward: use dedicated folders for bill storage, which most organisations already do.

Initial sync of large libraries takes time. If you connect a SharePoint document library with 10,000+ historical files, the first sync isn't instant. The system needs to traverse the folder structure, identify file types, and queue them for processing. Subsequent syncs are fast because they only pick up new files since the last timestamp.

Re-authorisation can happen. OAuth tokens refresh automatically, but if Microsoft revokes access (tenant admin changes, security policy updates, account suspension), you'll need to re-authenticate. We surface this clearly in the integration status dashboard rather than letting syncs silently fail.

It's configured per business unit. Each site or project needs its own folder mapping. For a company with 50 sites, that means 50 configuration steps. Not 50 hours of work — maybe 50 minutes — but it's not a single-click "sync everything" button. We did this deliberately because mixing all sites into one processing stream makes facility-level NGER reporting impossible to reconcile.

The regulatory timing argument

NGER reporters submit by 31 October each year. That means you need 12 months of complete utility data processed, validated, and calculated by August at the latest — leaving time for review, quality checks, and any corrections before the deadline. The Clean Energy Regulator doesn't grant extensions.

If you're manually collecting that data, you're typically doing it in batches — often starting the scramble in July or August. Documents get missed. Bills from Q1 weren't filed properly. Someone changed the folder structure in March and now nobody can find the water invoices for two sites.

With a live OneDrive sync, the data flows in continuously. By August, you don't have a three-week data collection sprint. You have 10 months of already-processed data and a short list of gaps to close. That's a fundamentally different position to be in, and it's why we think the carbon accounting OneDrive integration question isn't about convenience — it's about compliance risk.

ASRS Group 2 reporting starts from July 2026. Those entities need Scope 1 and 2 data with an audit trail that a financial statement auditor will review. And NGER reporters are automatically pulled into ASRS Group 2 via the registration pathway. So if you're already doing NGER, you're about to do both — using the same underlying utility data. Having that data flow directly from your existing document management system into a carbon accounting platform with a full audit trail isn't a nice-to-have any more.

Years of historical data, sitting untouched

Here's one more thing. Many Australian companies have three to five years of utility bills saved in SharePoint that they've never used for emissions reporting. They didn't have a reason to. NGER only applied to entities above the thresholds, and ASRS didn't exist yet.

Now those historical bills have value. Baseline year calculations for ASRS and SBTi require historical emissions data. Trend analysis for transition plans under AASB S2 paragraphs 14(a)(iv) needs year-over-year comparisons. Even a simple question from a board member — "have our emissions gone up or down over three years?" — requires processing historical data.

That historical data is already sitting in your SharePoint. Connect the folder. Let the initial sync run. Process three years of bills in days instead of hiring a consultant to do it over three months at $300-$500 per hour.

Set up the OneDrive connection for one site first. Pick the one with the cleanest folder structure and most consistent billing. Watch how the sync picks up documents and the pipeline processes them. Then roll it out to the rest. That's about 15 minutes of setup per site, and it pays for itself the first time a bill arrives and nobody has to type anything.