ERP Rescue Consultant, Portugal

Keeping documents flowing on the first day of the rescue

A Portuguese business cannot pause invoicing while a project is sorted out. So the first question in any rescue is simple: can the company issue every document it needs today, safely? I check it in a fixed sequence with your finance lead and the implementer:

1. Every series needed for current operations is active and was communicated as your accountant expects.
2. Invoices, credit notes and receipts carry the ATCUD code and QR element on every layout, including PDF copies and reprints.
3. Goods leaving a warehouse or site have transport documents where required, produced by the process rather than by memory.
4. Documents are issued from the program intended for them, not from a spreadsheet or a CRM template created in a hurry.

If any of these fails and cannot be fixed within days, the fallback is agreed with your accountant before anyone improvises. That might mean continuing to issue certain documents from the previous program for a limited time, or holding a specific document type until a fix is tested. I do not decide what is acceptable under the rules; your accountant and tax advisor do. I make sure the fallback is written down, owned and ended on time.

Only when documents are flowing safely does the wider recovery start. The general method is on my ERP recovery page; this page covers what Portuguese rules add to it.

A freeze on changes to how documents are created

Troubled projects generate pressure to fix things fast, and implementers respond by adjusting whatever is in front of them. In Portugal that habit carries a particular risk, because whatever standing an invoicing program has with the tax authority attaches to one product release, and altering the way it numbers, prints or builds documents could put that standing in doubt.

So the rescue introduces a narrow but firm freeze. Any change that touches invoices, credit notes, receipts, transport documents, series, layouts or the SAF-T export stops until three things are on file:

• the business reason, signed by the process owner;
• a written statement from the implementer, and where relevant the vendor, on whether the change affects compliance;
• a decision by management, with your accountant consulted when tax is involved.

Everything else continues through ordinary change control. The freeze is not a sign of distrust. It protects the implementer as much as the company, because neither side wants a quick fix that creates a larger problem later.

I also list changes already made during the troubled period, so the implementer can confirm in writing which ones touch document creation. Where nobody can say, the item is reviewed and, if needed, reversed in a test environment before anything goes back into production.

Repairing SAF-T, recharges and the month-end

Once documents are safe, the next pain is usually the close. Three areas tend to need repair together.

The SAF-T file. If your accountant cannot load or reconcile the file, I produce test exports for the affected periods and compare them with the ledger. Differences are traced to causes, such as customers without tax numbers, wrong country codes, documents issued elsewhere and posted only in summary, or manual journals that bypass tax logic. Causes are fixed in master data or configuration, and your accountant decides whether past periods need a correction.

Recharges. Service centers that invoice group companies often fall behind during a troubled project, and sister entities stop receiving their charges. I rebuild the backlog with finance, agree allocation keys and markups as documented by your advisors, and get intercompany invoices out with balances confirmed by the counterparties.

Payroll and bank. The monthly file from the accountant or payroll bureau is mapped again to the new accounts and cost centers, and bank reconciliations are brought current.

The goal is one month closed cleanly, with the accountant satisfied that the figures hold. That close becomes the base for everything else in the recovery. My ERP data migration page covers how source data problems are corrected without editing posted documents.

Reading the project honestly, with the implementer in the room

While the close is being repaired, I build a written account of how the project reached this point. I read the contract and the implementer's proposal against the requirements, the plan against the change log, and test records against the defect list, then hold private conversations with directors, department heads, everyday users and the implementer's lead.

The account rarely points to one culprit. Requirements may have been drawn from a demo, the company may have answered design questions late, document compliance may have been treated as a final-week task, or legacy data from a package such as PHC, Primavera or Sage may have needed more cleaning than anyone planned. Sharing the account with both sides tends to lower the temperature.

The reset session then classifies every open item as essential, deferred, dropped or disputed. Disputes are settled against the documents. Each remaining item gets a named owner and an acceptance test.

If the relationship cannot continue, the task becomes an orderly handover: configuration notes, localization extensions and who maintains them, custom code, credentials, open defects and test scripts, gathered before the implementer steps away. Questions about penalties, withheld payments or termination are for your lawyer, who reviews the Portuguese contract; I provide a neutral timeline and a scope comparison. I do not give legal advice.

Choosing a route and proving it before the next go-live

With documents safe and the facts on paper, management chooses a route. A brief route paper lays out the choices:

• Continue with the current platform and implementer under the reset plan.
• Narrow the first release to the parent company's accounting, purchasing and warehouse, adding hotels, shops or other sites in later waves.
• Split the design: a local invoicing program issues Portuguese documents and feeds the ERP, which keeps operations and group reporting.
• Change implementer while keeping the platform.
• Change platform, when even a well-run project would leave the software unable to serve the business.

Each option lists reusable work, main risks and cost drivers, without invented figures. The split design deserves an honest look in Portugal, because it can remove the document question from a struggling ERP, though it adds an integration to maintain.

Before any new go-live date is fixed, the compliance checklist is retested with real documents, your accountant reviews the outputs, and a go/no-go meeting decides on written criteria, as set out under ERP go-live support. Calls are booked in the Portuguese morning, inside my own working day. Afterwards, an ERP audit in Portugal confirms what remains. For a fresh choice of system or implementer, see my Portuguese ERP selection page, and the Portugal hub for everything else.