A men's footwear collection for the summer season easily exceeds 900 references — each one with combinations of size, width, colour and lining. No generalist ERP models this natively. What happens in practice: the company buys the generic ERP, pays for the implementation, and then pays again — in customisations, in parallel spreadsheets, in team hours spent reconciling data that the system cannot structure. This article argues an uncomfortable thesis: the generic ERP is not a cheaper option for Portuguese footwear. It is an option with deferred costs that only surface when it is already too late to change without pain.
The most expensive analytical mistake a CFO can make
The comparison begins and ends with the licence price. It is the worst mental shortcut available in the ERP decision for the footwear industry.
The licence price is visible, it is in the proposal, it has a line in the budget. The costs of adaptation, of maintaining customisations and of accumulated operational inefficiency do not appear in any proposal. They appear in the overtime of planning, in the shipping errors to buyers in Milan, and in the credit notes issued because the system did not distinguish the narrow size 42 from the standard 42.
The generic ERP is cheaper on the day of signing. The real cost difference only becomes visible eighteen months later — and rarely appears in a single cost centre.
The market context makes this decision even more critical. The Portuguese footwear industry exported 1,718 million euros in 2025, corresponding to around 68 million pairs — with growth of 3.3% to European markets, which absorb €1,420M, according to APICCAPS (February 2026). These are demanding buyers, who visit the factories in Felgueiras and Guimarães with increasingly dense technical specifications. In this context, an ERP that does not model footwear's native product structure is not a minor limitation — it is a structural handicap that is paid for collection after collection.
What the generic ERP cannot model natively
The size grid: where the data model breaks first
A generalist ERP treats the product as a combination of simple attributes: reference + colour + size. In footwear, the reality is different. A single reference can have three simultaneous axes — European size, upper width and lining type — with differentiated availability by axis. The grid is not linear: size 37 may exist in three widths, size 42 in two, and size 45 in only one. And size 45 consumes more leather than size 37 — which affects costing by size, not just by reference.
Modelling this in a generic ERP forces one of two choices, and both are bad. The first is to create a distinct reference for each combination — which explodes the item database and makes SCM unmanageable beyond a certain collection size. The second is to use free text fields and manage the logic in external spreadsheets — which guarantees shipping errors and makes automatic calculation of component requirements impossible.
A vertical ERP for footwear has the grid as a native structure. The customer order comes in with the size distribution. Production planning calculates component requirements based on that grid. The warehouse ships with automatic checking by size. There is no adaptation — it is the base data model.
The detail the manuals do not mention: the problem is not just wrong shipping. It is that without the native grid, MRP calculates raw material requirements based on size averages — and a collection with demand peaks in sizes 42 and 43 generates leather shortages even with "sufficient" stock in the system. The purchasing manager discovers it when the cutter stops the line.
Collection management: the life cycle the generic ERP does not know
The footwear industry works by collections. Each one has its own life cycle: sample development, buyer approval, order confirmation, production, shipping. International buyers visit the factories twice a year — men's footwear in August, women's in February — and what they present at the trade fair must be linked to what the system can plan and produce.
A generic ERP does not have the concept of a collection as a management entity. It has sales orders and production orders, without the temporal and commercial link that the collection cycle requires. The practical result is that capacity planning for the following season is done outside the system, approved samples have no automatic traceability to the production order, and the collection development cost sits in a generic cost centre — it never appears in the real margin per reference. The article on production capacity planning in the ERP explores this point in technical detail.
Component traceability: what the ESPR already requires
The European ecodesign for sustainable products regulation (ESPR), in force since July 2025, significantly increases traceability requirements on products placed on the European market — including footwear. The digital product passport will require the manufacturer to identify the origin of each component: leather, sole, glue, lining, laces.
A generic ERP without native batch-to-batch traceability cannot meet this requirement without extensive customisation. A vertical ERP already has the component structure linked to the production order, to the raw material batch and to the supplier — because it was always necessary to manage complaints from international buyers long before any European regulation required it. The article on batch-to-batch traceability in Portuguese industry details what the ERP must guarantee and what still remains on paper.
Where the second invoice appears
Initial customisation: the cost no one budgets in full
The generic ERP proposal normally includes a number of consultancy days for "adaptation to the sector". In practice, the size grid, collection management and component traceability are not configuration adaptations — they are software developments. The difference is critical: a configuration adaptation is maintained through system updates; a specific development is not.
Each version update of the generic ERP forces the customisations to be retested and, frequently, rewritten. The maintenance cost grows with the complexity of the business and with each new version from the vendor. After five years, the company has a system that no one wants to update because the update breaks what works — and a vendor that charges every time the market changes the rules.
The scenario that repeats itself in Felgueiras
In a footwear factory with 120 employees, the pattern is recognisable: the generic ERP manages accounting and sales; collection management is in a separate application developed by a freelancer eight years ago; the size grid is managed in an Excel file shared on the network; the warehouse uses manual picking with paper checking. The IT team — often a single person with 15 years of accumulated business knowledge — spends a significant part of their time reconciling data between these systems. This time does not appear in any ROI of the original implementation. It appears in the burnout of the person who does it.
The invisible risk: when that person leaves, the knowledge of how the systems communicate goes with them. What remains is a set of Excel files with formulas that no one fully understands and an integration that "works if you don't touch it".
Industrial costing: the margin no one calculates well
Costing by reference in footwear is structurally complex. It includes raw materials with variation by size, direct labour with variation by operation and by model, subcontracting of stitching and finishing, amortisation of moulds and tooling, and collection development cost. A generic ERP calculates costs by cost centre. A vertical ERP calculates the real margin per reference, per collection, per buyer.
The difference is not academic. It is the difference between knowing that the spring/summer collection was profitable in aggregate and knowing that the Oxford model in brown leather had a negative margin because the mould was amortised over too small a run — and that the same model in synthetic leather, at the same selling price, had a 23% margin. Without this granularity, the decision to repeat or discontinue a reference in the next collection is an intuition, not an analysis. The article on industrial costing in the ERP details how to move from the cost centre to the real margin per reference.
Technical comparison: vertical ERP vs. generic ERP in footwear
| Capability | Generic ERP | Vertical Footwear ERP | Operational impact |
|---|---|---|---|
| Native size grid | No — requires development | Yes — base structure | Shipping errors, incorrect stock, MRP by averages |
| Collection management | No — requires external module | Yes — integrated life cycle | Planning outside the system, development cost lost |
| Batch/component traceability | Partial — requires customisation | Yes — batch to component | ESPR non-compliance, complaints without quick response |
| Costing by reference/size | No — generic cost centre | Yes — margin per SKU | Collection decisions without real data |
| Integration with mobile sales force | Requires external integration | Native or pre-integrated | Outdated catalogues at the fair, unavailable references presented |
| DL 28/2019 compliance (ATCUD/SAF-T) | Depends on AT certification | AT certified | Legal and fiscal risk, invalidation of documents |
| Customisation maintenance cost | High — recurring per version | Low — standard functionality | Real TCO higher than forecast in proposal |
Trade-offs by company size
Companies up to 50 employees
The temptation of the generic ERP is greater because the licence price weighs more heavily in the decision. The risk is proportional: with fewer internal IT resources, the maintenance of customisations falls on the vendor or on a technician who takes on multiple roles. When that technician leaves, the knowledge goes with them. The question is not whether the company can implement a generic ERP — it can. The question is whether it can keep it functional as the collection grows and international buyers demand more traceability. The answer, in most cases we see, is no.
Companies between 50 and 200 employees
This is the most critical segment — and where the argument for the vertical ERP is strongest. They already have enough complexity for the limitations of the generic ERP to be painful: collections with 600 to 1,200 SKUs, multiple international buyers with distinct traceability requirements, subcontracting of operations to third parties that needs to be integrated into costing. But they do not yet have the size that justifies a large-scale ERP with an 18-month implementation. This is where specific functionality without the cost and duration of top-tier systems has the clearest argument.
Groups with multiple factories or own brands
Above this size, multi-company and multi-currency consolidation enters the equation. For groups with operations in Portugal and abroad, the choice may fall on a larger-scale ERP such as QAD Adaptive ERP, which combines low-code flexibility with deep industrial functionality without the code customisation costs that characterise adapted generic ERPs. The article on multi-company ERP in Portugal covers this scenario in detail.
Decision matrix: when to choose each approach
| Criterion | Generic ERP | Vertical Footwear ERP | Large-Scale ERP (low-code) |
|---|---|---|---|
| Company size | <30 employees, low complexity | 30–300 employees, footwear cluster | >200 employees, multi-country group |
| SKU complexity | Low (<200 simple references) | High (grid + collections + components) | Very high (multi-brand, multi-factory) |
| Traceability requirement | Minimal | High (ESPR, international buyers) | Very high (certifications, audit) |
| Typical implementation timeline | 3–6 months (without customisations) | 4–8 months | 12–24 months |
| Initial customisation cost | High (missing functionality) | Low (native functionality) | Medium (low-code configuration) |
| 5-year maintenance risk | High (customisations accumulate) | Low (sector standard) | Low (configurable platform) |
| PT fiscal compliance (DL 28/2019) | Verify AT certification | Included | Included |
What works in practice
Separating the ERP from the mobile sales force system — but with native integration
A common practice in the factories of the Felgueiras and Guimarães cluster is to use the vertical ERP for internal management — production, warehouse, finance — and complement it with a mobility solution for the sales force at trade fairs and customer visits. The native integration between the ERP and the sales application ensures that the catalogue presented at the fair is the same as the one in the system, with real availability and updated prices.
When this integration does not exist — or is done through files exported manually the night before the fair — the salesperson presents references that are no longer available, or prices that were changed after the export. The error is not the salesperson's. It is the architecture's.
Component traceability before the ESPR, not because of it
The factories that already had batch-to-batch traceability implemented before the ESPR did not do so in anticipation of regulation. They did it because international buyers had already been demanding supplier audits and materials compliance for several years. The European regulation came to formalise what the market already imposed. The operational lesson is direct: implementing component traceability as a response to a regulation is always more expensive and more disruptive than having it as a base functionality from the outset. The article on B2B collaboration with suppliers shows how to structure this flow without relying on email.
ABC analysis of references as a costing filter
In a collection with 800 to 1,200 SKUs, calculating the real cost of each reference with the same level of detail is unfeasible — and unnecessary. What works is to apply an ABC analysis to the references by volume and expected margin, and concentrate detailed costing on the A references, which typically represent the majority of turnover. The C references are managed with standard cost. This approach is only possible when the ERP has the data structure to support it natively — when the grid, costing by size and the link to the production order exist as a base model, not as a customisation.
In a collection of 1,000 references, those that truly determine the margin are frequently fewer than 150. The problem is that without the right ERP, you don't know which ones they are — and the decision is made by the salesperson's intuition.
Regulatory compliance: the invisible cost of the uncertified ERP
DL 28/2019 and AT certification
Decree-Law 28/2019 requires the use of invoicing programs certified by the Tax Authority. The monthly SAF-T communication (Ordinance 195/2020) is mandatory. A generic ERP that is imported or locally developed without AT certification puts the company at risk of a fine and of invalidation of fiscal documents. Always check whether the ERP you are evaluating has valid and up-to-date AT certification — not just whether it "supports" SAF-T. These are different things: supporting the format is a technical matter; having the certification is a legal matter.
NIS2 and the security of the management system
The NIS2 Directive (transposed into Portugal by DL 65/2025) extends cybersecurity obligations to sectors that were not previously covered. For footwear factories integrated into the supply chains of major international brands, the compliance pressure also comes from the buyers themselves — who audit critical suppliers with increasingly detailed security questionnaires. An ERP hosted on infrastructure without adequate security controls is a risk vector. Access management, data encryption and post-incident recovery capability are requirements that the ERP and the underlying infrastructure must meet together.
Ransomware does not choose the sector. It chooses the vulnerability. A footwear factory with the ERP exposed without multi-factor authentication is as valid a target as any other — and a three-day stoppage in the middle of collection production has a cost that no policy fully covers.
How to measure post-implementation success
The evaluation of a vertical footwear ERP should not be done at six months — it should be done at the end of the first complete collection managed in the system. The relevant indicators are not the vendor's; they are the business's.
The shipping error rate by size grid measures the number of credit notes issued for reference or size errors, compared with the previous period. The collection closing time — days between order closure and production planning confirmation — should reduce measurably: if it does not reduce, the system is not being used for what it was bought for. Component traceability coverage measures the percentage of production orders with an identified raw material batch; the target is 100% for A references. The real margin per reference calculated automatically measures the percentage of references with complete costing in the system, without the need for manual calculation in a spreadsheet. And the data reconciliation time between systems — weekly hours spent exporting, importing and correcting data between the ERP and external tools — should tend towards zero in the critical flows.
The MULTI ERP was designed with these metrics as functional requirements, not as configuration options. The size grid, collection management and component traceability are base structure — not additional modules. For companies with greater multi-company complexity or international operations, QAD Adaptive ERP offers a configurable platform without the code customisation costs that characterise generic ERPs adapted to footwear.
The final question is not "which is the cheapest ERP". It is "what is the total cost of not having the right functionality" — and in Portuguese footwear, that cost accumulates silently, collection after collection, until it appears in a buyer audit, in a wrong shipment to a customer in Milan, or in a notification from the AT about non-compliant documents.
Sources
- APICCAPS — Footwear Monitor, February 2026. Export data for the Portuguese footwear industry in 2025 (value, volume, markets).
- European Commission — Regulation (EU) 2024/1781 (Ecodesign for Sustainable Products Regulation — ESPR), in force since July 2025. Traceability and digital product passport requirements.
- Tax and Customs Authority (AT) — Decree-Law No. 28/2019, of 15 February, and Ordinance No. 195/2020, of 13 August. Electronic invoicing, ATCUD and SAF-T communication obligations.
- European Parliament and Council — Directive (EU) 2022/2555 (NIS2), transposed into Portugal by Decree-Law No. 65/2025. Cybersecurity obligations.
Frequently asked questions
Why can a generic ERP not model the footwear size grid?
A generic ERP treats the product as a simple combination of reference, colour and size. In footwear, a single reference can have three simultaneous axes — European size, upper width and lining type — with differentiated availability by axis. The grid is not linear: size 37 may exist in three widths, size 42 in two. The generic data model cannot structure this natively.
What is the impact of a poorly modelled size grid on the MRP?
Without the native grid, the MRP calculates raw material requirements based on size averages. A collection with demand peaks in sizes 42 and 43 generates leather shortages even with "sufficient" stock in the system. The purchasing manager discovers the problem when the cutter stops the production line.
What is a collection in the context of an ERP for footwear?
The footwear industry works by collections, each with its own life cycle: sample development, buyer approval, order confirmation, production and shipping. International buyers visit the factories twice a year to evaluate the new collections.
How does a generic ERP fail at collection management?
A generic ERP does not have the concept of a collection as a management entity. It only has sales and production orders, without the temporal and commercial link that the collection cycle requires. The result is that capacity planning stays outside the system and the traceability of approved samples is manual.
What is the true cost of a generic ERP for footwear?
The generic ERP is cheaper on the day of signing. The real costs — customisations, parallel spreadsheets, team hours reconciling data, shipping errors — only appear eighteen months later and rarely in a single cost centre. It is a deferred cost that only becomes visible when it is already too late to change without pain.
How does the ESPR regulation affect the ERP choice?
The European ecodesign regulation (ESPR), in force since July 2025, requires traceability of the origin of each component — leather, sole, glue, lining, laces. A generic ERP without native batch-to-batch traceability cannot meet this requirement without extensive customisation.
Why is the licence price comparison misleading?
The licence price is visible in the proposal, but the real costs of adaptation, maintaining customisations and accumulated operational inefficiency do not appear in any proposal. They appear in the overtime of planning, in the shipping errors and in the credit notes issued because the system cannot structure the reality of the footwear business.