AFAS vs custom software: how to choose?

What is AFAS Software, briefly and honestly?

AFAS Software is a Dutch ERP vendor based in Leusden with a dominant position among Dutch small and mid-sized businesses. Its flagship product, AFAS Profit, is an integrated suite that brings financial administration, payroll, HRM, project administration, tax filing, order management and CRM into one environment. The stack originally was on-premise; the vast majority of the installed base now runs on AFAS Online, the cloud variant.

AFAS has one trait that sets it clearly apart from international ERP players: the product was born in the Dutch context of tax, payroll and collective labour agreements (CAOs). Payroll tax, holiday allowance, CAO provisions, VAT returns, ICP listings: all of this belongs natively in the product and is updated every year for new legislation. At the same time, Profit, like any package, embodies a specific view of how an organisation works: great when your processes match it, restrictive as soon as they deviate. This article is about that trade-off: not bashing AFAS, not claiming that custom is always better, but getting clear on when each option fits.

An overview of the Profit modules

When weighing up AFAS, you need to know which modules do the work. Here are the three clusters we encounter most often.

Finance

Financial administration has historically been the core: general ledger, accounts receivable, accounts payable, fixed assets, project accounting, tax returns and consolidation. For Dutch SMEs, this layer covers almost everything a controller needs, with direct links to Belastingdienst (Dutch Tax Authority) flows. It is robust and well maintained, and most organisations running AFAS initially choose it for exactly this reason.

HRM, Payroll and InSite

The HR and payroll modules are AFAS's strongest offering in the Dutch market. Payroll calculation, expense claims, absence management, personnel records and the InSite employee portal all sit on the same database as financial administration. For organisations working under standard Dutch collective labour agreements (CAOs), payroll errors occur less often because there is barely any data transfer between systems to go wrong.

CRM, order management and projects

The picture is more nuanced here. AFAS CRM and order management work well for organisations with a transactional sales process and common quote and invoice formats. For commercial organisations with complex deal structures, multi-channel sales or their own customer experience, we more often see AFAS stay in place for finance and HR, while CRM and sales tooling sit outside Profit.

Where AFAS excels

A fair comparison begins by acknowledging where the package genuinely delivers. Here are four areas where AFAS consistently performs well.

Built-in Dutch compliance

Dutch payroll tax, holiday entitlements, transition payments, VAT corrections, ICP declarations: AFAS builds every year's Dutch tax and employment law updates into the product. If you write or commission your own payroll engine, you take on that maintenance burden, which is no small task. For organisations with no reason to carry that load, there is a great deal of value here.

End-to-end integration between modules

Because finance, HR, payroll, projects and CRM sit in a single data model, many classic integration bottlenecks disappear. A time registration against a project flows automatically into payroll calculation and invoicing. A new employee gets a personnel record, payroll entry, project role and user account in one step. With standalone SaaS tools, that work would need to be stitched back together manually.

Fit for the Dutch mid-market

AFAS is built for the scale and complexity in which most Dutch mid-market organisations operate. Implementation takes effort, but nowhere near the scale of an SAP or Oracle project. The Dutch implementation partner market is also mature, so you can find people who know the package well without too much searching.

InSite and OutSite portals

The built-in portals for employees and external parties cover a reasonable range of self-service needs: leave requests, expense claims, file access and applicant workflows. For organisations without specific branding requirements at those touchpoints, this is often sufficient. Later in this article, we explain when it starts to fall short.

Where package limits appear

No package covers everything. Here is a practical set of areas where we see AFAS users hitting walls.

Industry-specific workflows

Once a sector has working processes that aren't part of the standard modules, such as inspection rounds requiring photo and GPS evidence, production tracing by batch and lot number, or planning boards with domain rules that fall outside AFAS's project model, you reach the limits of what the package models. Custom fields help up to a point; beyond that, you end up working against the tool.

Customer or supplier portals with their own branding

InSite and OutSite are handy for internal and standard external flows, but they are no replacement for a commercial customer portal with its own brand identity, custom UX and more complex ordering or case-file functionality. For organisations that see their own customer portal or dealer portal as part of their proposition, a separate application with an integration to AFAS is almost always the better route.

Atypical integrations

Connecting with other systems is possible via AFAS Connect and the REST API, but the quality of the outcome varies by use case. Simple master data exchange works smoothly; more complex flows involving event-driven updates, high frequency or bidirectional synchronisation call for a carefully considered integration architecture around them. You can read more about how we set these up on our page about smart API integrations.

Reporting and customer-facing apps

AFAS offers reporting, but once you need to analyse broadly across modules, combine external data or provide dashboards for people without a Profit account, you end up needing your own data layer: a data warehouse or BI platform that pulls data from Profit via GetConnectors and enriches it externally. The same pattern applies to customer experiences: mobile apps, commerce layers, booking platforms or service apps are built separately and connected. AFAS is back office, not front office.

What is custom software in this context?

Custom software in an AFAS context rarely means "replacing AFAS entirely". Far more often it is software that lives alongside or on top of AFAS: a dedicated application for a specific process, a portal for a specific target group, an integration layer that links several systems together, or a data and AI layer that works on top of AFAS data.

Good implementation builds on standards — REST/JSON, OAuth 2.0, OpenAPI contracts, common event buses — so that the custom layer not only talks to AFAS but also to the rest of your stack. Its design depends on where the centre of gravity lies: close to AFAS (an extension to InSite with its own UX), more loosely alongside it (an operational application with asynchronous synchronisation of master data), or clearly above it (a data platform that draws on multiple sources and uses AFAS as one of its inputs).

The hybrid: AFAS as the backbone, custom software on top

In practice, the route we most often see working is a hybrid. AFAS remains the backbone for finance, HR and payroll; custom software fills the gaps where AFAS has no suitable module or where standard functionality falls short. In concrete terms, that means:

• AFAS Profit as the system of record for financial administration, payroll, employee records and the core registration of projects and relations.
• Custom application(s) for industry-specific operations: planning, inspections, production tracking, customer experiences, dealer or partner portals, AI-supported working.
• An integration layer that synchronises master data and transactions bidirectionally — employees, projects, customers, hours and invoicing where useful — via AFAS Connect or the REST API.
• A possible data platform that combines data from Profit with operational data from the custom application, plus external sources, for analytics, BI and AI applications.

The key design principle is: determine, for each data element, which system is the system of record. An employee lives in AFAS, a production batch in the custom application, an inspection photo in the custom application, a payslip in AFAS. Clear ownership prevents synchronisation spaghetti, recurring duplicate entry and conflicts where two systems overwrite each other's data.

AFAS Connect, REST API and GetConnectors

The integration side deserves its own section, because many hybrid projects stand or fall on it. AFAS offers roughly three integration routes; they are not mutually exclusive, and most serious integrations combine them.

UpdateConnectors and GetConnectors

The classic AFAS integrations run through Connectors: GetConnectors for reading data out of Profit, UpdateConnectors for writing it back. You configure in AFAS which fields you make available, and your custom system retrieves or sets that data via the Connect layer. For reporting and data warehouse purposes this is a sound route: stable, explicitly configured, and transparent about who sees what.

REST API

For a few years now, AFAS has offered a more extensive REST layer that makes modern integration patterns workable: synchronising master data, writing back transactions, and running queries across the data model. For real-time use cases, this is the more practical route. As with any vendor API, though, you should check the rate limits, plan for version changes, and build proper error handling.

File Exchange and EDI

For specific financial and HR flows, file exchange (XML, CSV, UBL) remains a serious option. Think bank statements, external payroll runs, or government tax filings. It isn't glamorous, but in compliance-heavy contexts it is often the more stable choice.

The right route depends on data volume, the need for real-time updates, and the complexity of the mapping. A candid proposal phase maps out the flows per data element before any building starts. You can read more about this approach on our page on integrations with existing systems.

An AI layer on top of AFAS data

A topic that comes up in almost every conversation is what you can do with AI on AFAS data. AFAS is building AI functionality into parts of the package itself, which covers a number of generic use cases. For organisations that want to go more specific, with their own models, prompts, knowledge sources and governance, a custom layer is the logical choice.

The practical design choice is not to build AI functionality inside AFAS, but in a separate environment that reads data via GetConnectors or REST, enriches it with other sources, and returns results through its own interface. Examples we see include invoice preparation with general ledger suggestions, contract analysis based on creditor data, HR alerts on absence or expense patterns, or a copilot for finance staff with questions about their own administration. Two points need attention: data governance (AFAS holds personal and financial data, so models, prompts and logs must be handled in line with GDPR) and human-in-the-loop (for finance and HR decisions, people remain responsible; AI flags and prepares, it does not decide).

A customer or employee portal with your own branding

InSite (employees) and OutSite (external parties) are AFAS's built-in portal solutions. For standard internal flows such as leave, expense claims and file access, they work well. For commercial customer portals, dealer environments, supplier sites with a distinctive user experience, or employee apps with a strong brand identity, we more often find that a custom front end is the better route.

That custom front end reads from AFAS via REST or GetConnectors, covering invoices, contract details, project status and file items, and writes back via UpdateConnectors where needed. The user experience can be designed entirely freely, while the data stays in Profit as the source of truth. The trade-off comes down to what the portal needs to deliver: only access to AFAS information, or also new functionality (interaction, configuration, content) that doesn't belong in AFAS. The more the second category matters, the stronger the case for a custom portal.

GDPR, Dutch payroll and eIDAS

Compliance questions in AFAS projects are rarely about AFAS itself, and more often about everything around it. Three chapters are worth considering.

GDPR and data residency

AFAS hosts AFAS Online in the Netherlands and has a DPA model that is familiar territory for Dutch organisations. For data that lives in AFAS, a large part of the GDPR context is therefore already covered. It becomes important as soon as you move data out of AFAS into a custom layer: where that layer is hosted, who has access, which sub-processors are involved, and how long you retain data. This needs to be stated explicitly in the design.

Dutch payroll collective labour agreements (CAOs)

Payroll, holiday allowance, transition payments, collective labour agreement rules: a complex, moving target that AFAS actively tracks. Building this yourself is feasible in edge cases (temp-agency structures, international elements), but rarely worthwhile as a bulk replacement. The pragmatic rule: keep payroll in AFAS and build custom work around it.

eIDAS, audit trails and logging

For sectors where eIDAS-compliant signatures or identification flows matter (legal, healthcare, government), AFAS offers integrations with a few providers; more specific flows go through a custom integration. AFAS keeps logs within Profit, which is enough for most finance and HR audits. Custom applications get their own audit trail that fits sector requirements: append-only logs, events linked to users, exportable evidence trails.

TCO and ownership: look beyond the licence

The TCO discussion is often skewed. A package licence looks predictable; custom looks expensive in the short term. Over the longer term, which is usually what matters, the picture is more nuanced.

What is often underestimated in package TCO: implementation costs at launch, licence escalation as users and modules grow, maintenance of custom fields and integrations, implementation partner work with every release, and workaround systems because the package cannot handle a particular process. None of these costs is unique to AFAS; they are the reality of packaged software.

What gets underestimated in the TCO of custom software: maintenance after go-live, security patches, framework upgrades, an ongoing dev budget, and the attention the integration layer between custom software and AFAS requires. Anyone who buys custom software and lets it age pays again later. In most hybrid projects, the AFAS licences stay what they are and the custom budget goes to the parts where the package is not the right solution. For a deeper look at custom software budgets, read our guide to custom software costs.

When AFAS is enough

The pragmatic test: AFAS probably covers your needs if you can agree with three of the statements below.

• Our financial processes are standard Dutch SME processes: general ledger, debtors, creditors, VAT, annual accounts.
• Our payroll administration follows common Dutch collective labour agreements without atypical arrangements.
• Our HR processes fit within standard leave, absence and file workflows.
• Our order process is straightforward: quote, order, invoice in predictable formats.
• Our customers don't need a distinctive branded portal; standard portals suffice.
• Our reporting needs sit within what AFAS offers natively or within a simple BI integration.

In that case you'd be short-changing yourself by spending money on custom software where you don't need to. AFAS rolls out faster than a greenfield build project, the Dutch network of implementation partners is broad, and they largely take care of compliance maintenance. Our advice, though: don't deploy the package as an island. Make sure the integration routes (Connect, REST, GetConnectors) are set up clearly, that data export paths are defined, and that you have a view of where you might want to add custom software in a few years.

When custom development pays off

Custom software pays off when you do something distinctive that doesn't fit the standard modules, or when the package's limits force you into workarounds that become more painful every year. Patterns we see time and again:

• Industry-specific operational processes that don't fit AFAS's project or order structure, from production tracking to inspection flows, from planning boards with domain rules to fleet management routines in logistics.
• Customer portals with a distinctive brand identity, for example a dealer portal, a client environment in construction, or a service portal for healthcare relationships with its own UX and functionality beyond what OutSite offers.
• Mobile applications for customers or employees that need offline capabilities, push notifications or native UX, and that combine data from AFAS with operational sources.
• AI applications on your own data — copilots for finance, pattern alerts for HR, contract or invoice analysis — where governance and model choice need to stay in your hands.
• Multi-system integrations where AFAS is one of several systems, and the integration layer is more complex than a simple Connect mapping.
• Operational data warehouses and analytics platforms that combine data from Profit with other sources, with dashboards that also work for people without an AFAS licence.
• Specific compliance or sector evidence flows that need their own registration and audit layer which does not belong in AFAS.

Not every pattern means a large greenfield project. Often the first custom step is small: one process that clearly does not fit AFAS, delivered as a separate application with an integration to Profit for the relevant master data. If you work with Exact Online yourself or are considering it, you will find a similar trade-off in our guide to Exact Online vs custom software — many of the patterns overlap.

How to decide: a workable process

No flowchart can make this decision for you. What does work is a four-step process.

1. Write down the processes, not the tool

Don't start with an AFAS shortlist or a custom-build request. Start with a document of a few pages describing how finance, HR, sales and operations actually work for you: who does what, which decisions get made, which data is involved, which laws and standards apply, and which other systems are involved. That document is your benchmark.

2. Run an honest fit analysis on AFAS

Hold that document up against AFAS Profit. Not "what does the brochure say?" but "what does the system do if we want this specific process in it?". Preferably with a proof of concept or an implementation partner experienced in your sector. What fits, what fits with adjustments within the package, and what clearly doesn't fit?

3. Make the custom question concrete

If processes remain that don't fit AFAS, or fit it poorly, describe what the custom layer should do — more specifically than "a system of our own". Which users, which flows, which integrations with AFAS, which compliance requirements? The less vague you are, the faster a serious build partner can come back with a sound proposal.

4. Plan for growth, not for an end state

Custom projects land best in phases: a minimal working version first, live in production, gain experience, then build further. The same applies to AFAS implementations (don't roll everything out at once) and to the integration layer (start with one bidirectional flow, expand based on what works).

Frequently Asked Questions

Can AFAS be entirely replaced by custom software?

Technically a lot is possible, but in practice it almost never pays off. AFAS's core value — financial administration and payroll with Dutch compliance maintenance — is a large body of work to build yourself and keep up to date. For most organisations, the hybrid route (AFAS for finance and HR, custom software for the rest) is wiser than a full replacement.

Is AFAS Online cloud-native?

AFAS Online is a hosted version of the package run by AFAS itself, on Dutch infrastructure. Operationally that is cloud-like (no server management of your own), but architecturally it is not multi-tenant SaaS in the modern sense. In practice this rarely matters; for specific integration or performance requirements, it can.

What if we are already deeply invested in AFAS?

Then the pragmatic question is not "should we migrate away?" but "where does a custom layer add value?". Start with one process that fits AFAS poorly, deliver it as a separate application with integration via Connect or REST, and build outward from there. Many hybrid engagements start small.

How does AFAS compare with Exact Online?

Both are Dutch suppliers with overlapping territory, but they have different characters. Exact Online is cloud-native by origin and stronger as pure financial SaaS administration; AFAS offers the broader suite (HR, payroll, projects, CRM). If you only need finance, an Exact comparison is more relevant; if you need integrated HR and payroll, AFAS sits closer to your requirements. For that angle, see our guide to Exact Online vs custom software.

Does AFAS work well with external BI tools?

Yes. Power BI, Tableau, Looker and in-house data warehouses can pull data from AFAS via GetConnectors or REST. Bear in mind data modelling: AFAS's internal model is not a one-to-one analytics-friendly star schema, so there is usually a transformation layer between Profit and your BI tool.

How much does a custom layer on top of AFAS cost?

That depends on scope: the number of flows, integration complexity, number of users, compliance context, and whether a mobile version is needed. A figure without context is misleading; a scoping conversation gives a more reliable picture. For background on how custom software budgets are built up, see our page on custom software costs.

How do you approach AFAS integrations?

For each data element, we determine which system is the source of truth. We then choose the Connect route (UpdateConnectors/GetConnectors, REST API, or a combination), model the mappings explicitly, and build retry, monitoring and logging paths. You can read more about this approach on our smart API integrations page.