Real estate

The group's utility invoice management (power and water, from providers like Iberdrola or Endesa) was fully manual. Every invoice that arrived by email forced the team to download the PDF, save it to a pending folder, open Business Central, locate the right provider and contract, create the invoice, post it, go back to the PDF, rename it with the internal number assigned by the ERP, and move it to the archive folder.

With ~15 entities inside the group and dozens of active contracts, premises and dwellings with different tax treatments, the process was repetitive, slow and error-prone: invoices posted to the wrong property, posting delays, duplicates in the archive, and an internal ERP number that always forced a second pass over the PDF.

In parallel, customer collections follow-up was done by querying the ERP by hand and assembling aged-debt reports customer by customer.

The priority was removing manual work from recurring invoices, without touching the human validation step for non-standard cases. The design rested on four decisions:

• A single parameterised workflow for the whole group instead of one flow per entity. With 15 companies, duplicating workflows would have made every future change unmaintainable.
• Google Sheets as a lightweight operational layer for data that changes often: contracts table, exclusion list, log of already-sent invoices to avoid duplicates. This lets the ops team adjust rules without touching the workflow.
• AI-powered OCR for data extraction. Each provider issues PDFs with its own format, and a vision model capable of reading the full invoice (provider, number, dates, taxable base, IGIC, total, contract number) handles new formats without rewriting code every time.
• Automatic invoice ↔ contract matching through the contract number that appears in the PDF, cross-referenced against the contracts table, which determines the property and accounting account the expense belongs to.

Phase 1. Automated reception and storage Emails with invoices are detected automatically in the corporate inbox. The PDF is extracted, uploaded to Google Drive into the "pending to register" folder, and made available to the rest of the pipeline. This block runs without human intervention.

Phase 2. Extraction and matching against contract Extraction relies on an AI-powered OCR (vision model) that reads each PDF and returns the structured fields: provider, invoice number, dates, taxable base, IGIC, total and contract number. Those data points are cross-referenced against the contracts table to automatically determine the property and the correct accounting account.

Phase 3. Creation and posting in Business Central The workflow creates the draft invoice in the ERP, adds the line with concept and amount, and posts it. The ERP returns the internal number, which is used to rename the PDF and archive it in its final folder with the correct name.

Phase 4. Parallel flow: issued invoicing and collections reporting In parallel, the system automates the emailing of issued invoices (with duplicate control) and the customer aged-debt report, which mirrors the ERP's native format and is distributed automatically by email to the finance team.

The payables pipeline is live for the providers with the highest recurring volume. An invoice from these providers no longer requires any of the 8 original manual steps: it enters via email, appears posted in the ERP, and is archived with the right name — without human intervention.

The issued-invoicing flow and the weekly collections report are also in production, replacing manual tasks that used to consume hours of the finance team's time every week.

Each provider issues invoices in a different format, and that format can change over time. An AI-powered OCR handles that variability and absorbs format changes without needing to intervene each time.

Giving the finance team a place of their own to onboard new clients with their accounting accounts makes day-to-day operations highly efficient.

Business Central's standard APIs don't expose everything: custom fields and certain tables require publishing pages as OData Web Services. That has to be factored in from the design stage.