A chief financial officer at a weaving mill in the Vale do Ave received a notice from the AT: an €18,000 discrepancy between the SAF-T submitted and the actual warehouse movement. The ERP had recorded everything. So had the SAF-T. But neither of them cried out when the manual picking diverged from the batch coding. The invoicing was correct. The tax was paid. The file that came out of the machine was "clean". End of story. Except it wasn't — because the product costing was 7% above reality, and nobody had seen it.
This is the truth that no tax compliance software warns you about: the SAF-T can be impeccable while your ERP works with fictitious data. In 2025, only 53.7% of companies in Portugal (10+ employees) used integrated business management software — and of those, most treat the ERP as a transaction recorder, not as an integrity watchdog. We see this frequently in factories and warehouses with complex stock movement (textiles with colours and knits, footwear with sizes and fittings, metal components with unique serial numbers): the SAF-T becomes a mirror of what the ERP believes happened. Not of what actually happened. And the cost of that operational blindness does not appear on the tax return — it appears in product costing, in purchase forecasting, in production planning, and ultimately in the margin that the system says it has but doesn't.
Tax compliance is not the same thing as operational accuracy. A correct SAF-T can come from incorrect data.
The ERP doesn't know what it doesn't see
A SAF-T file is a snapshot of transactions: incoming document, item code, quantity, price, cash movement. The ERP extracts this from its database and assembles the file. All correct, from the machine's point of view. But the ERP only records what was entered or imported. If an operator picked 12 units when the system asked for 15, and nobody corrected the difference that day — perhaps because the order was partial, perhaps because the batch had a defect that was discovered late — the SAF-T will report 15. Nobody warns that 3 are missing.
Or: a batch of raw material arrived with a manual (paper) goods receipt note. The driver delivered 500 kg, but the warehouse weighing recorded 487 kg due to moisture. The ERP received 500 (as per the delivery note). The SAF-T reports 500. The Tax Authority sees 500. The reality? 487. And if that batch fed a series of production runs, each one of them carries a fictitious cost that will contaminate the costing of the entire subsequent series.
Three leakage points that nobody measures
First: mismatch between receipt and warehouse. The delivery note says 100 units. The warehouse weighs, counts or checks and finds 97. If the user makes a manual credit note, the ERP becomes aware. If they don't — perhaps because "it's only 3%" or because the difference will be absorbed in the next movement — the SAF-T goes out with 100. Months later, an internal audit finds that the physical stock doesn't match the system. The SAF-T has already been submitted. The tax compliance certificate is done. The account close-off is left pending. In projects we have followed, we have found companies with a receipt divergence rate of between 2% and 5% — which means that a warehouse with monthly movement of €50,000 accumulates between €1,000 and €2,500 of "difference" that nobody has formalised.
Second: batches with quality divergence or that get stuck in quarantine. A yarn purchase arrives with partial defects. The batch goes into quarantine. The goods receipt note was processed (the SAF-T sees the receipt). But the return was made by telephone, via email, or documented only on paper. The system never saw the outgoing movement. The system stock includes a batch that doesn't exist in the warehouse — it's scrap, it's waste, it's an asset that has become a liability. The SAF-T reports an asset that physically disappeared weeks ago.
Third: production with unrecorded waste or with undocumented internal transfers. A footwear factory produces 80 units of a model. 5 come out defective (scuffing, stitching failure). Those 5 are destroyed. But the production order closed with 80 in the system. Nobody created a "scrap" or "destruction" document in the ERP. The SAF-T sees 80 outgoing. The warehouse has 75. The difference is absorbed as "process variation", which is a euphemism for "we don't know". When the CEO asks what the actual production yield is, the answer comes inflated because the system doesn't see the scrap.
The hidden cost of compliance without visibility
When a CEO asks "how much is this discrepancy costing us?", the typical answer is: "No cost. The SAF-T passed, the AT accepted it, the tax was paid." That's true. But it's incomplete. The cost is elsewhere.
It's in product costing that becomes inflated because the raw material batch has a fictitious weight. It's in the purchase forecast that is based on a stock that isn't real — and that leads to ordering too much or too little. It's in production planning that allocates resources to make 100 units when only 97 arrived, generating delays that nobody can explain. It's in the margin that the system says it has but doesn't really have, because the production cost was calculated on a quantity that isn't real. A distributor we have followed had an impeccable SAF-T for two years. But its product costing system was 7% above reality because the warehouse receipt had a divergence rate of 3-4% that nobody had formalised. When it decided to do a stock adjustment, it discovered it had €140,000 of accumulated difference. It wasn't tax fraud. It was operational invisibility — and it cost a complete redefinition of margins, a review of sales prices, and a loss of internal confidence in the planning system.
Tax compliance is necessary. But it is not sufficient to run a company.
What the ERP should warn about (and often doesn't)
A good ERP should have controls that trigger alerts when there is a divergence between the expected and the recorded. Some do this well. Many don't. A vertical ERP for industry should warn when the receipt of a purchase diverges by more than 2% from the delivery note — not let the user pass. It should warn when a batch stays in quarantine for more than 30 days without movement, because that is an asset that is rotting. It should warn when a production order closes with quantities that don't match the raw material consumption — because that means there is undocumented scrap. It should warn when a manual stock movement (adjustment) is greater than 1% of the monthly value moved, because large and frequent adjustments are a symptom of lack of control. It should warn when a supplier return has no associated receipt document, because that is an orphan transaction.
These controls exist. But they require careful configuration. They require that the user has previously defined what the acceptable tolerance is for each type of divergence. They require that the ERP is not just a transaction recorder, but an integrity watchdog. Most companies we see use the ERP as a filing cabinet. Not as a controller. And then they are surprised when they discover that their SAF-T is perfect, but their data is not.
Honesty about our own mistake
Five years ago, when we were implementing the MULTI ERP, we used to tell clients: "We certify the software with the AT, the SAF-T comes out automatically, you have guaranteed compliance." It was true. But it was incomplete. We did not alert them to the fact that tax compliance is not the same thing as operational accuracy. A correct SAF-T can come from incorrect data. We learned this through real implementations, through internal audits of clients who discovered discrepancies, through CFOs who told us: "Your system said everything was fine. But my stock doesn't match." We learned this through a textile factory that had a 4% divergence between the system and the physical count, and that only discovered it when it tried to do an internal audit for a PT2030 funding application. We learned this through a metal components distributor that had 23 supplier returns documented only on paper, because "the system had no field for that".
Today we know that the responsibility is not only to certify the file. It is to help the client have accurate data before the file goes out. It is to configure alerts that cry out when there is an anomaly. It is to train the user to see the ERP not as an archive, but as a controller of reality.
What to do now
If you are a CEO or COO of an industrial company, ask three questions at the next IT meeting. One: what is the divergence rate between the receipt of purchases (delivery note) and the warehouse record? If it's greater than 1%, you have a data integrity problem that is contaminating the costing. Two: when was the last time we did a complete physical stock count (and compared it with the system)? If it was more than 12 months ago, your SAF-T may be reporting fiction. Three: does your ERP have alerts configured for anomalous movements — purchases with divergence, returns without receipt, adjustments above threshold, batches in quarantine for more than 30 days? If it doesn't, you are working in the dark.
The SAF-T is a file. What matters is what goes inside it. And what goes inside it is determined by the integrity of the data that the ERP saw — or that it pretended to see.
Read also: Production capacity planning: what the ERP calculates and what it misses, MES without ERP integration: the hidden cost the COO doesn't see, and ERP and private label: traceability and costing in production on behalf of others.
Frequently asked questions
What is a SAF-T discrepancy and why doesn't the ERP detect it?
A SAF-T discrepancy occurs when the file submitted to the AT reflects data that the ERP recorded, but which does not correspond to operational reality. The ERP only sees what was entered or imported — if a manual picking diverged from the batch coding or if a receipt was not formalised, the system doesn't warn because it has no information about that divergence.
What is the difference between tax compliance and operational accuracy?
Tax compliance means the SAF-T is correct and the AT accepts it. Operational accuracy means the data in the ERP corresponds to the reality of the warehouse and production. A SAF-T can be impeccable while the ERP works with fictitious data, causing errors in product costing and planning.
What are the three main data leakage points in industrial production?
First: mismatch between receipt and warehouse (delivery note says 100, warehouse has 97). Second: batches in quarantine or with defects not formalised as a return. Third: unrecorded production waste — for example, 5 defective units destroyed but the system closed the order with 80. None of these generate a tax alert, but all of them affect the costing.
How does a receipt divergence affect product costing?
If a batch arrives with 487 kg but the ERP records 500 kg (as per the delivery note), each product manufactured from that batch carries a fictitious cost. That cost contaminates the entire subsequent series of production runs, inflating the real costing. Months later, the physical stock doesn't match the system, but the SAF-T has already been submitted.
What is the real financial impact of an unformalised discrepancy?
The impact does not appear on the tax return, but it affects product costing, purchase forecasting, production planning and the reported margin. A company with a divergence rate of 3-4% on receipt can accumulate tens of thousands of euros of difference, leading to a review of sales prices and a loss of confidence in the system.
Why does a batch in quarantine become a problem in the SAF-T?
The goods receipt note is processed (the SAF-T sees the receipt), but if the return was made by telephone, email or only on paper, the system never records the outgoing movement. The system stock includes a batch that does not physically exist in the warehouse, becoming an asset that disappeared but that the SAF-T continues to report.
What should an ERP warn about when there is a divergence between the expected and the recorded?
A good ERP should trigger alerts when the receipt of an order doesn't match the delivery note, when a batch stays in quarantine without a formal return document, or when actual production diverges from the production order. Many ERPs treat themselves as transaction recorders and not as watchdogs of operational integrity.