SAF-T (AO): How to Generate the Accounting File From Your ERP Without Manual Reconciliation | Blog

# SAF-T (AO): How to Generate the Accounting File From Your ERP Without Manual Reconciliation

TL;DR: Angola's SAF-T (AO) accounting file is a different file from the SAF-T invoicing file, has its own deadline (April 10, covering the prior fiscal year), and e-invoicing does not exempt you from it — it only reduces the obligation to submit invoicing SAF-T. If your operational chart of accounts isn't built to generate this file automatically, you'll be closing it by hand every year.

There is one confusion that is easy to make and expensive to keep: treating "SAF-T" as a single file. It isn't. Angola's tax authority, the Administração Geral Tributária (AGT), requires two distinct SAF-T (AO) files, with different purposes, structures and deadlines — and the reform introduced by Presidential Decree 71/25 of March 20, 2025, which made e-invoicing mandatory, has made that distinction more important to get right, not less.

This article is written from the perspective of people who build ERP systems for the sector — not from a tax or legal perspective. The goal is to explain the actual engineering problem: how an ERP that already handles accounting, projects/contracts, wells and inventory can produce this file without the finance team spending weeks reconciling numbers in Excel before every submission.

Two files, two purposes

SAF-T (AO) exists in two variants that the AGT treats separately:

Invoicing SAF-T — extracts sales documents (invoices, credit/debit notes, receipts) for a period, structured around commercial documents.
Accounting SAF-T — extracts the entirety of a full fiscal year's accounting movements: chart of accounts, third parties (customers/suppliers), tax table, and every general ledger entry, each with a unique key attached to the transaction.

These are generated by different modules of the system (invoicing vs. general ledger), submitted at different points in the year, and serve different audit purposes. Confusing the two — or assuming that solving one solves the other — is the most common mistake we see in teams preparing for their first submission.

The deadline that matters: April 10, prior-year data

According to EY Angola, the SAF-T (AO) accounting file must be submitted by April 10 of each year, with data covering the prior fiscal year — meaning the file submitted in April 2026 covers the full set of accounting movements from 2025 (EY Angola).

There is a timing nuance here worth not ignoring, because it changes what is urgent. AGT granted an adaptation period: submission of the accounting file for the 2025 financial year is optional and carries no penalties; the obligation applies to the 2026 financial year, filed in 2027 (KPMG Angola). That is not a reprieve — it is the only window in which you can generate the file, see what breaks, and fix the chart of accounts without a fine. The required data structure is set out in Executive Decree No. 317/20 of 14 December.

This deadline runs in parallel with the Inventory SAF-T, which has an annual submission deadline of February 15 of the following year — though the AGT has already extended that deadline to April 15, 2026 for the 2025 fiscal year (EY Angola). In practice, the two files — accounting and inventory — end up landing in nearly the same window of the financial calendar, which increases pressure on teams that still rely on manual closing.

Don't take a fixed deadline published on a third-party blog at face value: the AGT has a track record of adjusting dates by public notice. What is stable is the principle — the file always covers the prior fiscal year and is required annually, not per event.

E-invoicing does not replace the accounting SAF-T

This is the central confusion this article was asked to clear up, and the short answer is: e-invoicing exempts you from part of the invoicing SAF-T, never from the accounting SAF-T.

Presidential Decree 71/25 and Executive Decree 683/25 of August 22, 2025 (which defines the data structure of invoicing software and the technical specifications of the communication model) make electronic invoice issuance and communication mandatory from January 1, 2026 for large taxpayers, state suppliers, and taxpayers issuing invoices valued at 25 million Kwanzas or more. For all other taxpayers, the obligation only takes effect on January 1, 2027, with voluntary adoption possible during 2026 (EY Angola; Cegid Angola).

What changes once a company adopts e-invoicing, per Cegid Angola, is that "from the moment a company adopts e-invoicing, communication of invoices via SAF-T will only occur if the AGT requests it" — meaning there is no longer a regular obligation to submit the invoicing SAF-T, because the AGT already receives the documents in real time through certified software, with post-transaction validation (Cegid Angola).

This has no bearing whatsoever on the accounting SAF-T. Accounting remains an annual exercise of closing, consolidating and extracting the general ledger — none of that is replaced by communicating invoices in real time. An operator or EPC contractor that has already adopted e-invoicing and assumes it has "SAF-T covered" is conflating the two files, and will be caught off guard in April when the accounting file is requested.

The real engineering problem: mapping the operational chart of accounts

This is where most of the effort actually goes — and where most SAF-T projects fail silently until it's too late.

Angola's reference chart of accounts is the Plano Geral de Contabilidade Angolano (PGCA), approved by Decree 82/01 of November 16, 2001, structured into classes (inventory, third parties, monetary means, capital and reserves, income, costs, results, among others). This is the structure the AGT expects to recognize accounts against in the SAF-T file. The problem is that no ERP built for oil and gas operations management uses PGCA in its pure form.

An ERP built for upstream, production, projects/contracts, procurement and maintenance typically organizes the general ledger with additional dimensions layered on top of the chart of accounts: cost center by well or field, project/contract code (for cost-sharing under a Joint Operating Agreement), asset class for MRO and fleet, and withholding tax codes applied by supplier type. None of these dimensions exist in PGCA — and SAF-T has no field for "well" or "AFE" (Authorization for Expenditure). The engineering work is precisely this: deciding, account by account, where each combination of account + cost center + analytical dimension maps within the account structure the file requires, without losing the granularity the operation actually needs internally.

Three concrete problems show up systematically in this mapping:

1. Too many "catch-all" accounts. Under deadline pressure, finance teams create "miscellaneous" or "other" accounts to avoid interrupting the monthly close. These accounts have no clean correspondence in PGCA and require retroactive manual reclassification before the SAF-T can be generated — exactly the work the file was supposed to eliminate.

2. [Multi-currency](https://wise-hustlers.com/blog/erp-multi-moeda-aoa-usd-operacoes-petroliferas) without an exchange rate traceable to the entry. Contracts in USD, local expenses in Kwanza, and a SAF-T file that requires values in the reporting currency traceable to the exchange rate applied on each transaction. If the ERP only stores the converted balance and not the rate used line by line, the reconciliation has to be redone after the fact.

3. A unique key per transaction. SAF-T (AO) requires a unique key/hash attached to each entry. Systems where entries remain editable after posting, or where closing reprocessing occurs, break this uniqueness and generate files the AGT rejects on validation.

None of these problems is about "generating XML" — the export itself is trivial once the data model is correct. The hard work is making sure, month after month, that the operational general ledger is born mappable, rather than corrected by hand in March.

What goes wrong when accounting lives in Excel

The hardest case is the oilfield service company that still runs accounting partly in spreadsheets, with the ERP covering only operations (procurement, inventory, fleet) while accounting is consolidated manually outside the system. There, four problems stack up at once:

The "official" general ledger never exactly matches the operational one. Manual adjustments made in Excel to close the month never get posted back into the ERP, so the SAF-T extracted from the system is systematically out of step with what was reported to the AGT the prior year.
There's no stable key per entry. A spreadsheet doesn't generate unique identifiers and doesn't prevent re-editing of already-closed values — the minimum requirement of SAF-T.
Year-end close takes weeks, not days, because reconciliation between the operational system (ERP) and the accounting one (Excel) only happens once a year, under pressure from the April 10 deadline, instead of being an automatic byproduct of the monthly close.
After-the-fact audit is impossible to defend. When the AGT asks for the detail behind a SAF-T line, the finance team has to manually reconstruct where the number came from — because the number never existed as a single, traceable entry inside one system.

The root cause isn't a lack of accounting discipline — it's the absence of a single system of record. As long as "real" accounting lives partly outside the ERP, generating SAF-T will keep being an annual reconciliation project, not an export.

How to structure SAF-T extraction from the ERP

Wise Hustlers builds and operates its own energy-sector ERP. The approach that comes out of that treats this as a data engineering problem applied to accounting, not as an "export report" feature:

1. A single operational chart of accounts, mapped to PGCA at the source. Every new account created in the ERP has a defined correspondence to the required account structure from the moment it's created — not a translation exercise done in April.

2. Analytical dimensions (well, contract, cost center) as attributes of the entry, not as separate accounts. This preserves operational granularity without polluting the chart of accounts with artificial accounts created purely for reporting.

3. Exchange rate and unique key managed at the entry level, not the balance level. Every general ledger line stores the rate applied and an immutable identifier generated at the moment of posting.

4. File generation as a scheduled, testable job, not a manual script. SAF-T stops being an annual panic event and becomes something you can generate (and validate against the prior year) every month, catching drift early.

This is the kind of work — designing the accounting data model and extraction pipelines so regulatory files come out correct the first time — that we do in our Data Analytics service, applied specifically to operational ERPs in the energy sector.

Checklist before submission

Does the ERP's chart of accounts have a documented, tested correspondence to the PGCA account structure?
Does every entry have a unique key generated at the moment of posting, and does that key survive closing reprocessing?
Are the exchange rates applied stored at the transaction level, not just the final balance?
Are there closing adjustments made outside the ERP (Excel, email) that never get posted back into the system?
Has the file been generated and validated against a closed fiscal year before the April 10 deadline, with time to fix discrepancies?
If the company has already adopted e-invoicing, does the team understand that this does not exempt it from the accounting SAF-T?

FAQ

Do the accounting SAF-T and the invoicing SAF-T share the same deadline?

No. They have distinct structures, purposes and submission calendars. The accounting file is due April 10, covering the prior fiscal year; the invoicing file is now only communicated on AGT request once a company has adopted e-invoicing.

If I already issue electronic invoices, am I exempt from generating SAF-T?

You're exempt from the regular submission of the invoicing SAF-T. You remain obligated to submit the accounting SAF-T every year, because it covers the full general ledger, not just sales documents.

From when is e-invoicing mandatory?

Since January 1, 2026 for large taxpayers, state suppliers, and taxpayers issuing invoices valued at 25 million Kwanzas or more. For all other taxpayers, the obligation takes effect January 1, 2027, with voluntary adoption possible during 2026.

What's harder to solve technically — the file export or the chart of accounts mapping?

The mapping. XML export is a solved problem once the data model is correct. The real work is making sure every account, cost center and entry in the ERP is born mappable to the required structure, without depending on manual reclassification before submission.