Third-Party Integration for Carbon Accounting: The Five Access Modes Every Australian CIO Should Know

An ASRS Group 2 mandate lands on the CIO's desk with the sustainability team's shopping list attached. Twelve data sources. Six systems. Two cloud tenants. A finance ERP the sustainability team has never had read access to. A field ops team that keeps everything in email attachments. And a board-level deadline that lands before the next quarterly integration release train.

The reflex answer is a project. Scope it, staff it, run it for six months, ship a middleware layer, hope nothing breaks. That's what carbon accounting integration used to look like. It's not what it has to look like now.

Why one integration pattern is not enough

Carbon accounting draws data from systems that were never designed to talk to each other. Utility bills arrive as PDFs from three different retailers. Fuel dockets get photographed in a truck cab and emailed. The finance ledger holds procurement spend. A building management system logs kWh in fifteen-minute intervals. A fleet telematics tool has litres burned per shift. Sustainability data providers push emission-factor updates monthly.

No single integration pattern fits all of that. An API works for the ERP. It doesn't work for the field electrician holding a paper invoice. A folder sync works for accounts payable dropping PDFs into SharePoint. It doesn't work for the AI query the CFO wants to run at 9pm on a Sunday. This is the core design constraint. And it's the reason API-only carbon accounting tools force the spreadsheet back into the workflow for anything that isn't already in a database.

We built Carbonly with five distinct access modes because that's how many patterns it takes to actually cover the real data sources in an Australian enterprise. Each mode has a different security profile, a different user, and a different failure mode. The CIO's job isn't to pick one. It's to know which one fits where.

Access mode 1: the web UI

The baseline. Someone in the sustainability team logs in, uploads a document, and the AI document engine reads it. This mode always works, needs no IT project, and covers the long tail of ad-hoc documents that will never fit into a systematic feed.

We keep the web UI as first-class because most other integration modes are actually just automated versions of what the UI does. A PDF that arrives via OneDrive sync goes through the same 8-format AI document engine as a PDF uploaded through the browser. Same 5-tier material matching. Same confidence scoring. Same audit trail. The plumbing changes; the extraction doesn't.

Role-based access control gates who can do what. Six built-in roles (Owner, Admin, Manager, Contributor, Auditor, Viewer) plus a separate Supplier Portal role for external counterparties who need to hand you data without seeing yours. That RBAC applies to every other access mode too. There is no back door.

Access mode 2: per-project email ingestion

Every project in Carbonly gets its own inbound email address. Something like pilbara-camp@inbox.carbonly.ai. Anyone who has that address can forward a document to it. The document lands in the project's processing queue, gets classified, extracted, and matched to an emission factor. No login required from the sender.

This mode exists because we watched the pattern in construction and mining. The site manager gets a fuel docket from a delivery driver at the shed. They photograph it. If getting that photo into a carbon system requires a login, a project selection, an upload dialog, and a confirmation screen, it doesn't happen. If it means forwarding an email, it happens.

The security boundary matters here. The ingestion path is write-only. The service that receives your email cannot read data belonging to any other tenant. The routing address itself encodes the project, so the mail cannot be misfiled. And the AI document engine flags duplicates by content fingerprint, so a well-meaning site manager who forwards the same docket twice doesn't double-count.

This is the mode built for construction-scale document volume, where dockets come off a dozen sites a day in a dozen different layouts. Not because anyone sold a site on a portal. Because the drivers already knew how to email a photo.

Access mode 3: OneDrive and SharePoint folder sync

Most Australian enterprises run on Microsoft 365. Accounts payable already drops utility invoices somewhere in SharePoint. Facilities managers already keep meter reads in a OneDrive folder. If your carbon system can watch those folders, ninety percent of the manual upload burden disappears.

Carbonly connects to OneDrive and SharePoint through Microsoft Graph. An Admin or Manager (the "connector user") authenticates once with OAuth, picks a folder, and the sync worker takes over. Delta sync tracks additions, changes and deletions on a fifteen-minute interval. New documents land in the same processing queue as everything else. See the deeper walkthrough of the OneDrive/SharePoint pattern for the setup flow.

Two design choices are worth calling out for the CIO who has to sign off on this.

First: the OAuth tokens are held by the connector user only. Regular users of the Business Unit see the previewed documents but never touch the token. If the connector user leaves the org, the integration flags for re-authentication rather than silently continuing under a phantom identity. This matches how carbon accounting data governance should be structured under an ASRS assurance regime.

Second: file previews are served through an internal document-proxy route. When an Auditor or Viewer opens a preview, we re-fetch from Graph using the connector's token at view time. No public preview URL sits in a database waiting to leak. The auditor sees the source document; the auditor never sees the credential.

The one honest limitation: Graph delta sync isn't instantaneous. A document dropped into SharePoint typically appears in Carbonly within fifteen minutes, sometimes within one. If your workflow needs sub-minute latency for a document arrival, use the API instead.

Access mode 4: REST API and outbound webhooks

For anything the other modes don't cover, the API does. Emission records, projects, documents, targets, plans, reports. Every table the web UI writes to is reachable through a REST endpoint scoped to the caller's organisation and role. No hidden admin surface, no read-only mirror that lags the live data.

The interesting piece for enterprise integration is not the API. It's the outbound webhooks. Instead of your ERP polling Carbonly to check whether an emission record was created, Carbonly pushes an event to your endpoint the moment it happens. Standard events include emission.created, document.processed, anomaly.detected, report.generated, and subscription.updated.

Every webhook delivery is HMAC-signed. Your endpoint verifies the signature against the per-subscription secret before trusting the payload. If your endpoint returns 4xx or 5xx, we retry with exponential backoff (one minute, five, twenty-five, two hours, ten hours). After five consecutive failures, we auto-disable the subscription and require a manual re-enable. Your on-call engineer doesn't get paged at 3am by a Carbonly retry storm.

The admin UI at /settings/webhooks lets the Owner add an endpoint, rotate the secret, browse the delivery log, and manually replay a failed delivery. That last capability matters more than it sounds. If your ERP goes down for maintenance on a weekend, you replay the missed deliveries on Monday instead of reconstructing them.

Access mode 5: Connect ChatGPT or Claude directly to your carbon data

This is the mode that surprises people. You can point ChatGPT, Claude Desktop, Cursor, or any agent that speaks the same protocol at your Carbonly organisation, and it can query your live emission ledger, run compliance checks, and generate reports on your behalf.

We shipped this because we watched the CFO's actual workflow. On a Sunday night, they don't want to log into a portal. They want to ask their AI assistant: "What was our Scope 2 for the September quarter, broken down by state, and how does it compare with the same quarter last year?" And they want a real answer sourced from real data, not a hallucinated number.

The way this works: Carbonly runs a small server on its side that exposes a defined set of tools to the external AI. When you connect ChatGPT or Claude to your organisation, that AI can call those tools with the same tenant scoping and RBAC as you'd have in the web UI. Ask a question, it queries. Ask it to run an anomaly scan, it triggers one. Ask it to generate an NGER report, it does. Every action lands in the audit trail with the source flagged as an external AI, so an assurance reviewer can see exactly what was done.

The full walkthrough of that flow (Claude Desktop config, ChatGPT connector setup, and the guardrails) lives in Connect ChatGPT and Claude to your carbon accounting. The short version: it's read-heavy, write-lite by default. Actions that create or modify data are gated by the user's role and the org's autonomy setting (Shadow, Co-pilot, or Trusted).

We're still working out the right defaults for autonomous actions in this mode. Trusted mode lets an external AI file emission records without a human approval; that's the right choice for a high-volume operation with strong data quality controls, and the wrong choice for a business that's still finding its footing. Set it accordingly.

How to combine access modes

The mistake is thinking you have to pick one. The design goal is that each data source uses the mode that fits it best. Here is what a typical mid-tier Australian construction group ends up with:

Data source	Access mode	Why
Fuel dockets from site	Per-project email	No login needed in the truck cab
Utility invoices (accounts payable)	OneDrive/SharePoint sync	AP already drops them there
Refrigerant service reports	Web UI upload	Ad-hoc, low volume, needs judgement
ERP procurement spend	REST API	Structured, systematic, hourly cadence
Emission events to data lake	Outbound webhooks	Push, not poll
Executive ad-hoc queries	MCP via ChatGPT or Claude	Natural language beats a dashboard for one-off questions

None of these modes locks you in. You can pull your entire dataset back out through the API at any time. You can turn off the AI integration mode without affecting your web UI users. You can rotate the OAuth tokens on a schedule. The five modes coexist because they solve different problems.

The one shared assumption underneath all of them: the same emission ledger, the same audit trail, the same emission factor library. There is no separate "API data" that diverges from "UI data." A document that arrives via email is indistinguishable at the ledger level from a document uploaded through the browser or synced through OneDrive. That's what makes the modes composable.

Enterprise identity

Every access mode terminates at a user or a service identity. For an enterprise deployment, those identities live in your IdP, not in Carbonly. We support SAML 2.0 and OpenID Connect for single sign-on, with per-org connections. Upload your IdP metadata XML for SAML; provide a discovery URL and client credentials for OIDC. Both IdP-initiated and SP-initiated flows work.

Just-in-time user provisioning at first login gives the new user the org's default SSO role. From there, the Owner or Admin can promote or restrict as needed.

For automated user lifecycle, we implement SCIM 2.0 at /api/scim/v2/*. Standard operations: list, create, update, and delete users and groups. Your IdP provisions and deprovisions Carbonly seats the same way it does Microsoft 365 or Salesforce.

One deliberate design choice worth flagging: SCIM deletes are soft. When your IdP deletes a user, Carbonly marks the record as deleted but does not drop the row. This is an audit-trail invariant. NGER record retention (s.22 of the NGER Act) requires you to be able to retrieve who authored an emission record for at least five years after the reporting year. A user who filed emission data three years ago must remain retrievable in the audit trail even after they leave the company. Hard-deleting the row would break that. Soft-deletion satisfies both the IdP's expectation and the regulator's.

Multi-factor authentication supports security stepup for sensitive actions. Rotating an API key, approving a report submission, changing an org-wide setting: those actions can require a fresh MFA challenge even inside an already-authenticated session.

API keys with scoped permissions and IP allowlists

Not every integration needs a human identity. A nightly ETL job pulling emission records into a data warehouse needs its own credential. That's what scoped API keys are for.

An Owner or Admin generates an API key from the settings UI. The key has an explicit permission scope (read-only, read-write, or specific resource types) and an optional IP allowlist. If the allowlist is set, requests from any other IP are rejected before authentication even runs. Combine this with your VPN egress IP or your data warehouse's known egress range, and a leaked key is meaningfully harder to abuse.

Keys are visible once at creation, hashed after that, and appear in a key management UI where they can be revoked or rotated. Every API call made with a key logs the key ID against the action. If a key needs to be pulled, you can see exactly what it did.

What Carbonly does not do

We don't push data directly into SAP, Oracle Financials, Dynamics 365, or Workday. There is no native connector that opens a session against your ERP and writes rows.

That's a deliberate choice, not an oversight. Direct ERP write-back requires a per-customer implementation project, is fragile against ERP version upgrades, and creates a support tail we're not set up to carry. Instead, we import from any accounting or ERP system three ways: CSV or Excel export dropped into a synced folder, a PDF export processed by the AI document engine, or an API push from your side (or a middleware tool like Boomi, MuleSoft, Workato) into the Carbonly REST endpoint. See why an ERP CSV plus a VLOOKUP is not a carbon accounting system for the deeper argument on why the ERP-first path breaks down anyway.

We also don't do direct write-back into ISCA IS rating tools, the TfNSW Carbon Estimate and Reporting Tool, or the Climate Active submission portal. We hold the underlying data; the submission is a reporting view on top of it, exported to whatever format the recipient wants. Same principle: no fragile per-recipient connectors, no lock-in.

FAQ

Do we need to pick one access mode at go-live and stick with it? No. Most orgs start with one or two (usually web UI plus OneDrive/SharePoint sync), then add API and webhooks once the first quarter's data is running clean, and turn on the AI integration mode when the executive team asks for it. Nothing about turning on a new mode disrupts the ones already working.

What happens to our data if we leave Carbonly? Every emission record, document, and audit-trail entry is reachable through the REST API, scoped to your organisation, with your admin credential. You can pull a full export at any time. There is no proprietary format that requires our help to read.

How is per-project email routing kept tenant-safe? Each project gets a unique inbound address. The service that receives the mail can only insert into the documents queue for the project that owns the address; it can't read tenant data or route to a different tenant. Cross-tenant leak requires simultaneously compromising the receiving path and the project mapping, which are separated by design.

Can the AI integration mode be turned off if our security team objects? Yes, per organisation and per user. An Owner can disable the AI integration entirely, or restrict it to specific users, or restrict it to Shadow mode (read-only, no writes). The RBAC applies whether you're in the web UI, using the API, or talking to Carbonly through ChatGPT.

What does this cost? Per-project pricing starting at $100 per month per project. There is no separate fee for API access, webhooks, SSO, SCIM, or the AI integration mode. If you have a specific stack you want to walk through before committing, email hello@carbonly.ai and we'll do the whiteboard session with you.

If your ASRS or NGER program is being scoped right now and your integration architecture is the blocker, start with a single project. Point the OneDrive sync at whichever folder your utility bills already land in. Add the email inbox for site fuel dockets. Give it a quarter. Then decide whether the API and webhook layer earns its keep. That's the sequence that avoids the six-month integration project the sustainability team was quietly braced for.