Skip to main content

ERPL Speaks More Than SAP Now

· 4 min read
Joachim Rosskopf
Joachim Rosskopf
Co-Founder & CEO

ERPL started as a DuckDB extension for SAP. That's still its center of gravity. But over the past few months it grew arms — into Microsoft 365, into Microsoft Dynamics 365, into the rest of the modern enterprise data surface.

Today's update to erpl.io makes that official. The landing page now reflects what ERPL has quietly become: a SQL gateway to your whole enterprise stack.

What's new since you last checked​

If your mental model of ERPL is "RFC, BICS, ODP" — we've added a lot since.

Microsoft 365 — Graph API coverage is broad and deep now.

  • SharePoint Lists with read, write, and ATTACH ... TYPE sharepoint_lists catalog support.
  • Excel Workbooks that you reference by site and file name instead of GUIDs — ATTACH 'sales-2026.xlsx' AS book (TYPE excel_workbook, SITE 'finance.sharepoint.com').
  • Microsoft Teams — teams, channels, members, messages.
  • Outlook — emails, calendar events, and contacts. The trio is feature-complete with lazy streaming for tenant-scale reads.
  • Microsoft Planner — read plans and tasks, and bulk-create tasks from a lateral join.
  • Entra ID — users and sign-in logs for audit and identity analytics.

Microsoft Dynamics 365 — both ERP and CRM are addressable.

  • Business Central ships with the same catalog-attachment pattern: ATTACH 'CRONUS Germany AG' AS bc (TYPE business_central) makes the whole company queryable. Company names are resolved automatically — no GUIDs.
  • Dataverse / Customer Engagement is there too, with $expand for related records and predicate pushdown.

SAP, beyond what you remember.

  • SAP Analytics Cloud — read models, stories, and planning data, with ATTACH ... TYPE sac for catalog access.
  • Datasphere got real OAuth2 secrets and both analytical and relational reads.
  • ODP now handles delta tokens cleanly — proper CDC, no row loss on paginated reads.

Open standards.

  • Delta Sharing consumes feeds from Databricks, SAP, S3, or Azure with bearer-token profiles.

Quality-of-life things you'll notice.

  • Reference Excel drives, SharePoint sites, Teams channels, BC companies, and Datasphere assets by name, not by GUID.
  • Trace logs redact Authorization headers, Set-Cookie, form-encoded secrets, and JSON tokens. You can crank tracing to TRACE in production without painting your logs with credentials.

Three things that are fun to try​

1. A Business Central company, as a DuckDB catalog​

ATTACH 'CRONUS Germany AG' AS bc (TYPE business_central);

SELECT no, name, balance_due
FROM bc.customer
WHERE balance_due > 0
ORDER BY balance_due DESC
LIMIT 20;

ATTACH does metadata discovery once; from then on every entity in the company looks like a table.

2. An Excel workbook, by name​

ATTACH 'sales-2026.xlsx' AS book (
  TYPE excel_workbook,
  SITE 'finance.sharepoint.com'
);

SELECT region, ROUND(SUM(amount), 2) AS pipeline
FROM book.Pipeline
WHERE stage IN ('Proposal', 'Negotiation')
GROUP BY region
ORDER BY pipeline DESC;

This used to require fetching the site GUID, then the drive GUID, then the file ID. Now it's just the site host and the file name.

3. SAP customers, joined to a SharePoint list​

ATTACH 'finance.sharepoint.com' AS sp (TYPE sharepoint_lists);

SELECT
  k.kunnr     AS sap_customer,
  k.name1     AS sap_name,
  c.Title     AS contract_name,
  c.End_Date  AS contract_end
FROM sap_read_table('KNA1') AS k
JOIN sp.Contracts AS c
  ON c.SAP_Customer_ID = k.kunnr
WHERE c.End_Date < now() + INTERVAL '90 days';

A SAP table on the left, a SharePoint list on the right, one query. Both ends of the join scale: predicate pushdown on the SAP side, OData $filter on the SharePoint side.

Why this matters​

The teams that adopt ERPL early all had the same shape of problem: their analytical data didn't live in one place. SAP held the ledgers; SharePoint held the contracts; Business Central held the operating company; Dataverse held the customer relationships; Excel held the spreadsheet someone refused to migrate.

The traditional answer was a pipeline per source — ingest into a warehouse, schema-on-write, build pipelines, maintain them. ERPL takes a different angle: keep the data where it is, and let DuckDB ask each system in its own dialect. ATTACH makes that ergonomic. Predicate pushdown makes it fast. Name-based resolution makes it humane.

The point isn't that ERPL replaces your warehouse. It's that the modeling layer between you and your enterprise systems just got a lot thinner.

What's next​

The DuckDB-shaped hole in your enterprise stack is filling up. Come pull on the loose threads with us.