Bitontree built Triple I, a Vienna-based ESG and sustainability reporting company, a full-stack platform that turns real-world ESG inputs into report-ready metrics. The system accepts spreadsheets, receipts, invoices, and live database connections, uses Azure OpenAI GPT-4 to map inconsistent data into a standardized ESG schema, and automatically generates 20+ workforce and emissions KPIs with on-demand PDF and DOCX reports. Delivered end to end over 6 months.
Austria
ESG & Sustainability Reporting
AI ESG Reporting Platform
6 months
AI engineers + full-stack engineers + Project Manager
Location:Austria
Industry:ESG & Sustainability Reporting
Project Type:AI ESG Reporting Platform
Duration:6 months
Team:AI engineers + full-stack engineers + Project Manager
Triple I is an ESG and sustainability reporting company that helps organizations collect, structure, analyze, and report sustainability data across workforce and environmental domains. As ESG disclosure requirements grew more complex, Triple I needed a platform that could simplify how its clients handled scattered data: inconsistent spreadsheets, invoices, receipts, database records, and reporting outputs.
Triple I wanted a scalable ESG data processing and reporting platform that removed the manual work behind sustainability reporting, letting users upload data in the format they already had and turning raw inputs into normalized ESG metrics, dashboards, and reports.
ESG reporting depends on data from many disconnected sources. Workforce data lives in HR systems, emissions data is spread across utility bills, travel receipts, invoices, and spreadsheets, and financial figures come from separate business tools. For Triple I's clients, this meant a slow, repetitive process: collecting data manually, cleaning it, reformatting it, reconciling it, and copying it into multiple templates before any useful KPI reporting could happen.
ESG data arrived in different file formats, column structures, naming conventions, and units, so teams had to manually reformat spreadsheets before anything could be processed.
Receipts, energy invoices, travel bills, and hospitality documents required manual reading and re-keying before their emissions data could be used.
ESG KPIs such as workforce composition, turnover, training hours, GHG emissions, energy usage, and intensity ratios all required repeated manual calculation across reporting cycles.
There was no single workflow connecting ingestion, validation, transformation, KPI generation, and reporting, and enterprise-grade security was needed for access, credentials, auditability, and organizational data separation.
Letting an AI model reshape inconsistent spreadsheets into a fixed ESG schema is useful only if it never guesses wrong without saying so. A column mislabeled as the wrong gender category or a misread unit would flow straight into KPI calculations. The hard part was building schema mapping that knows when it is unsure, so low-confidence fields get flagged for human review instead of being mapped silently.
Enterprise clients wanted to pull ESG data straight from PostgreSQL, MySQL, SQL Server, and AWS RDS rather than exporting files by hand. That meant holding database access for systems we did not own. Storing long-lived credentials in plain configuration was not acceptable, so the connectivity layer had to handle encrypted credential storage and short-lived access in a way that stayed safe across many client organizations.
Every reporting cycle, Triple I's clients lost time to data wrangling before any sustainability metric could be trusted. Mismatched spreadsheets, re-keyed receipts, and repeated KPI math left room for transcription errors and inconsistent figures across periods. ESG reporting under CSRD and ESRS leans on S1 workforce and E1 emissions data, so a mapping mistake or a silently dropped field could carry through into the reports that clients depend on. The platform had to remove the manual steps without quietly changing what the data meant.
Our embedded team designed the platform around a single normalized ESG data model so Excel files, extracted document data, connected databases, and REST API sources all flow into one common pipeline before reaching the KPI engine and reporting layer. The stack pairs a Next.js frontend with a Python and FastAPI backend on PostgreSQL, with Azure OpenAI GPT-4 driving schema mapping, Xapture handling AI document processing, and Azure Blob Storage and Azure Key Vault securing files and credentials. We load-tested with Locust and deployed on Azure via Gunicorn and Uvicorn. We treated documents as a first-class data source, built ESG-specific KPI logic for S1 workforce and E1 emissions, and moved heavy file transformation into background jobs so users keep working while large files process.
Users upload spreadsheets in their existing format with no template prep. Azure OpenAI GPT-4 analyzes column structures and maps them to Triple I's standardized ESG schema, handling inconsistent names, varied layouts, merged headers, and value-level differences like gender labels and unit variations. When a field can't be confidently mapped, the platform flags it for review instead of silently dropping or misclassifying data.
A single ingestion and normalization pipeline serves every data source. Whether data comes from an Excel file, a scanned document, a live database, or a REST API, the platform validates, transforms, and stores it against the correct company, organizational unit, and reporting period, so the KPI engine and reporting layer never need source-specific logic.
For emissions data locked in receipts, invoices, bills, and scanned files, we integrated Xapture. Users upload PDFs or images such as travel receipts, hospitality invoices, energy bills, and vehicle documents; Xapture extracts the required fields and returns structured JSON that moves through the same ESG pipeline as spreadsheet data, removing manual data entry.
Automated KPI calculations span two ESG domains. For S1 workforce analytics, the platform calculates workforce composition, gender distribution, disability representation, turnover, training hours per employee, and workplace injury rates. For E1 emissions, it calculates energy consumption, GHG emissions by scope, emissions by organizational unit, renewable energy share, emissions intensity, and SBTi target progress. KPIs generate automatically once source data is normalized.
We built connectors for PostgreSQL, MySQL, SQL Server, AWS RDS, and REST APIs so enterprise clients could connect existing systems directly. The layer includes real-time connection testing, schema discovery, table preview, encrypted credential storage, and role-based access. For AWS RDS, we implemented IAM-based authentication using temporary STS tokens to avoid long-lived credentials.
PDF and DOCX report generation lets users create ESG reports across S1 and E1 domains on demand from live platform data. The Next.js frontend covers dashboards, upload flows, data connection management, and user administration, while the backend adds JWT authentication, OTP verification, invite-based onboarding, role management, audit logs, and a credit system with automatic refunds for failed jobs.
| Dimension | Manual ESG Reporting | Triple I Platform |
|---|---|---|
| Data preparation | Reformat every spreadsheet by hand before anything can be processed | Azure OpenAI GPT-4 maps inconsistent columns to the ESG schema, flagging anything unclear |
| Document data | Read receipts, invoices, and bills and re-key the figures manually | Xapture extracts the fields and returns structured JSON into the same pipeline |
| KPI calculation | Recalculate workforce and emissions KPIs in spreadsheets each cycle | Over 20 workforce and emissions KPIs generated automatically once data is normalized |
| Data sources | File uploads only, with no path to live systems | Excel, PDFs, images, PostgreSQL, MySQL, SQL Server, AWS RDS, and REST APIs |
| Security | Ad-hoc credential handling with no central control | Encrypted credentials in Azure Key Vault, IAM and STS tokens for RDS, plus audit logs |
| Report output | Copy and paste figures into report templates | On-demand PDF and DOCX reports generated from live, validated data |
Triple I was built on a stack chosen for reliable data processing, accurate schema mapping, and secure enterprise connectivity.
Bitontree delivered a production-ready ESG reporting platform that turned a manual, fragmented workflow into an automated data processing system. Instead of asking clients to clean and format data before reporting, Triple I can now accept real-world inputs and convert them into structured, report-ready ESG metrics.
500-row Excel files are processed end to end in under 1 minute, with AI schema mapping removing the manual formatting that used to precede every upload.
Over 20 workforce and emissions metrics are generated automatically once source data is normalized, improving consistency across reporting cycles.
The platform ingests Excel files, PDFs, images, PostgreSQL, MySQL, SQL Server, AWS RDS, and REST APIs, so clients connect real systems instead of relying on file uploads alone.
On-demand PDF and DOCX reports run off live data, while role-based access, encrypted credentials, OTP, audit logs, and invite-based onboarding give Triple I a secure, scalable base for ESG reporting automation.
Don’t just take our word for it - our track record reflects our expertise and success.
AI-powered invoice processing for a Singapore-based logistics enterprise. OCR and ML automate data extraction, validate against business rules, and process invoices end-to-end across multiple formats and currencies.
It ingests ESG data from spreadsheets, documents, databases, and REST APIs, maps it into a standardized ESG schema, and automatically generates over 20 workforce and emissions KPIs. Users can then produce PDF and DOCX sustainability reports on demand from live, validated data.
Azure OpenAI GPT-4 analyzes each uploaded spreadsheet's column structure and maps it to Triple I's ESG schema, handling varied names, layouts, merged headers, and unit differences. When a field can't be mapped confidently, the platform flags it for human review rather than guessing.
Yes. We integrated Xapture so users can upload PDFs or images such as travel receipts, energy bills, and hospitality invoices. Xapture extracts the relevant fields and returns structured JSON that flows through the same normalization pipeline as spreadsheet data, removing manual data entry.
The platform uses JWT authentication, OTP verification, invite-based onboarding, role-based access, and audit logs. Database credentials are stored encrypted in Azure Key Vault, and AWS RDS connections use IAM-based authentication with temporary STS tokens to avoid long-lived credentials.
The platform supports S1 workforce reporting (composition, gender distribution, disability representation, turnover, training hours, injury rates) and E1 emissions reporting (energy consumption, GHG emissions by scope, emissions by unit, renewable energy share, intensity ratios, and SBTi target progress).
S1 covers workforce reporting and E1 covers emissions reporting under the ESRS framework that CSRD draws on. On the platform, S1 includes workforce composition, gender distribution, disability representation, turnover, training hours, and injury rates, while E1 includes energy consumption, GHG emissions by scope, emissions by organizational unit, renewable energy share, emissions intensity, and SBTi target progress. The platform supports reporting across both domains rather than certifying compliance on your behalf.
Azure OpenAI GPT-4 maps each uploaded spreadsheet's columns to Triple I's ESG schema, handling varied names, layouts, merged headers, and unit differences. The key safeguard is that it does not force a guess. When a field cannot be mapped confidently, the platform flags it for human review instead of silently dropping it or assigning it to the wrong category, so a mapping it is unsure about never quietly flows into your KPIs.
Yes. We built connectors for PostgreSQL, MySQL, SQL Server, AWS RDS, and REST APIs, with real-time connection testing, schema discovery, and table preview before any data is pulled. Credentials are stored encrypted in Azure Key Vault, and AWS RDS connections use IAM-based authentication with temporary STS tokens so there are no long-lived credentials sitting in configuration.
