↓

Business Central aanpassen: van instellingen tot eigen extensies

Business Central laat zich op drie niveaus aanpassen: instellingen, bestaande extensies en eigen development in AL. U leest wanneer welke route loont en wat dit betekent voor uw updates.

Bijgewerkt op 28 oktober 2026

Wie op zoek gaat naar Business Central development, heeft meestal een concreet probleem: een offerteflow die niet past, een rapport dat de boekhouder mist, een koppeling met de webshop. Het goede nieuws is dat de oplossing niet altijd uit code bestaat. Het slechte nieuws is dat verkeerd gekozen maatwerk jaren later nog kosten veroorzaakt. Deze pagina helpt u de juiste route te kiezen, en vooral te beoordelen wie het werk mag doen.

Drie niveaus van personalisatie

Bij de personalisatie van Business Central loont het om altijd van licht naar zwaar te redeneren. Elk niveau heeft een eigen prijs in tijd, risico en onderhoud.

Niveau Wat het inhoudt Wanneer kiezen Effect op updates
Instellen Parameters, rollen, workflows, rapportindelingen, pagina's per gebruiker Het proces bestaat al in de standaard Geen
Bestaande extensie Een toepassing uit Microsoft AppSource of een koppeling van een leverancier Een gangbaar probleem met een kant-en-klare oplossing Beheerd door de leverancier
Eigen ontwikkeling Een extensie in AL, speciaal voor uw bedrijf Het proces is uw concurrentievoordeel en bestaat nergens Voor uw rekening

Een nuttige vuistregel: ga pas een niveau dieper wanneer u kunt uitleggen waarom het ondiepere niet volstaat. Dat bespaart bij elke latere update een gesprek.

Eerst instellen, dan pas bouwen

Veel Vlaamse kmo's vragen maatwerk voor iets wat Business Central al kan. Controleer daarom vóór elke ontwikkeling of de modules van Business Central het gevraagde al dekken. Denk aan goedkeuringsstromen voor inkoopfacturen, extra dimensies voor analytische boekhouding, aangepaste verkoopdocumenten of rolgebonden startpagina's.

Daarnaast bevat de client de Designer. Daarmee past u pagina's aan door velden te herschikken of toe te voegen en het resultaat meteen te bekijken, zonder de interface te verlaten. Voor een functioneel beheerder is dat een snelle manier om een scherm te vereenvoudigen. Het resultaat is zelf een extensie, dus het blijft beheersbaar.

Een praktisch gevolg: een goed programma van eisen scheidt wat u wilt (het resultaat voor de gebruiker) van hoe het gebouwd wordt. Zo ontdekt u vaak dat de helft van de wensen een instelling is.

Bestaande extensies gebruiken

In de online versie breidt u Business Central uit met applicaties die u vanuit Microsoft Marketplace installeert. Het gaat om extensies van Microsoft zelf en van onafhankelijke ontwikkelaars. Er zijn bijvoorbeeld pagina's voor connectiviteit en voor bankkoppelingen, waarmee u bankverrichtingen kunt inlezen.

Een goed voorbeeld is de Shopify-connector. Die synchroniseert producten, voorraden, klanten, bestellingen, verzendingen en uitbetalingen tussen Shopify en Business Central, ondersteunt meerdere webshops en neemt ook bestellingen van Shopify POS en B2B mee. De synchronisatie kan in de achtergrond draaien via de takenwachtrij (job queue), met een gedetailleerd logboek voor het opsporen van fouten. Wie een webshop heeft, bouwt dit dus niet zelf.

Let bij een externe extensie wel op drie punten:

  • Onderhoud: wie past de extensie aan wanneer Business Central een nieuwe versie krijgt?
  • Lokale dekking: Microsoft levert de lokalisatie voor België rechtstreeks, maar een extensie van een derde hoeft Belgische gebruiken (btw, Peppol, bankformaten) niet te kennen.
  • Afhankelijkheid: wat gebeurt er met uw data als de leverancier stopt?

Bij koppelingen en integraties komen deze vragen sneller terug dan bij gewone functionele uitbreidingen.

Eigen ontwikkeling in AL

Is er echt niets dat past, dan bouwt een developer een extensie. Business Central wordt aangepast met extensies in de programmeertaal AL, geschreven in Visual Studio Code. Daarmee voegt u tabellen, pagina's, codeunits en rapporten toe of wijzigt u ze, zonder de basiscode aan te raken. De extensie wordt gecompileerd tot een .app-bestand.

Dat principe is de reden waarom maatwerk in de cloudversie veel veiliger is dan vroeger: de standaard blijft van Microsoft, uw wijziging ligt eromheen.

Werken in een sandbox

Ontwikkelen gebeurt niet in de productieomgeving. De sandbox-omgevingen zijn bedoeld voor development: het debugpunt staat standaard open en u publiceert vanuit Visual Studio Code. Uitgaande HTTP-aanroepen van extensies zijn er geblokkeerd tot u ze per extensie toestaat. Dat is geen last maar een veiligheid: een nieuwe extensie kan niet ongemerkt data naar een externe dienst sturen.

Eigen API's en limieten

Business Central biedt een REST-API (v2.0) om de ERP te verbinden met oplossingen van derden. Online staan de API's standaard aan. Let op: velden toevoegen aan een standaard-API kan niet. U moet de AL-code kopiëren en een eigen API maken. Dat is een typisch voorbeeld van maatwerk dat nodig is en toch beperkt blijft.

Houd ook rekening met de gebruiksgrenzen voor OData V4, die per gebruiker gelden: vijf gelijktijdige aanvragen, honderd verbindingen en een schuivend venster van 6 000 aanvragen per vijf minuten. Daarboven antwoordt de dienst met HTTP-code 429. Microsoft raadt API of OData aan in plaats van SOAP, dat bedoeld is om te verdwijnen. Een koppeling met massa's kleine oproepen is dus slecht ontworpen, ook als ze in een testomgeving wel werkt.

Wat maatwerk betekent voor updates

De klassieke angst van elke kmo: "als we aanpassen, zitten we vast". In Business Central is die angst deels achterhaald, maar niet volledig. De extensie raakt de standaard niet, dus Microsoft kan de basis blijven bijwerken. Wat wel kan misgaan:

  • een extensie die steunt op onderdelen van de standaard die Microsoft wijzigt;
  • een koppeling die niet meer klopt met de API-versie;
  • een rapport of pagina dat na een update anders werkt;
  • een developer die niet meer bereikbaar is op het moment dat het misloopt.

Daarom hoort een testronde in een sandbox bij elke update. Hoe versies en edities zich verhouden, leest u op de pagina over versies en edities van Business Central. Wie dit niet wil dragen, spreekt het onderhoud af in een supportcontract voor Business Central.

Bonne praktijken: standaard, documentatie en tests

Eigen ontwikkeling is geen probleem; ongedisciplineerde ontwikkeling wel. Vier gewoonten onderscheiden een duurzame extensie van een tijdbom.

  1. Blijf bij de standaard waar het kan. Elke afwijking is een toekomstig onderhoudspunt. Vraag bij elke wens: "Welke standaardfunctie komt het dichtst in de buurt?"
  2. Documenteer de bedoeling, niet alleen de code. Een functionele beschrijving per extensie: wat doet ze, waarom bestaat ze, wie is eigenaar, welke processen raakt ze. Zonder dat verdwijnt kennis met de developer.
  3. Test voor elke update. Automatische tests voor kritieke processen (verkoop, inkoop, facturatie) en een handmatige controle door een sleutelgebruiker in de sandbox.
  4. Houd de code in versiebeheer en bij u. U moet kunnen aantonen wie wat heeft gewijzigd en u moet de broncode kunnen opvragen. Maatwerk dat enkel bij de leverancier ligt, maakt u afhankelijk.

Een Belgisch voorbeeld waar discipline loont: facturatie. Elke aanpassing aan verkoopdocumenten raakt het btw-gedrag en de e-facturatie. Lees vooraf de pagina over e-facturatie en Peppol en laat uw boekhouder meekijken, want een elegante lay-out die een verplichte vermelding mist, is een fout, geen detail.

Hoe beoordeelt u een Business Central-developer of integrator?

Maatwerk staat of valt met wie het bouwt. Of u nu een kleine ontwikkelaar kiest of een grotere partij, stel dezelfde vragen. Hoe u het hele traject aanpakt, staat in het artikel over het kiezen van een ERP-integrator en in de pagina over de keuze van een integrator voor Business Central.

Vraag Goed antwoord Waarschuwing
Hoe begint u een opdracht? Met uw proces, daarna pas de oplossing Meteen een offerte voor code
Wat doet u met standaardfuncties? Eerst onderzoeken of ze volstaan "Dat bouwen we wel"
Waar test u? In een sandbox, met een testscenario Rechtstreeks in productie
Wie bezit de code? U, of toegang tot de broncode is contractueel geregeld De code blijft bij de leverancier
Hoe documenteert u? Functionele beschrijving per extensie Alleen codecommentaar
Wat na de oplevering? Onderhoud en updatetests zijn afgesproken Niemand weet wie verantwoordelijk is

Vraag ook of de partij ervaring heeft met Belgische vereisten. Microsoft levert Business Central rechtstreeks gelokaliseerd voor België, maar uw eigen processen (bankformaten, btw-aangiftes, sectorspecifieke documenten) vragen vaak aanvullend werk. De pagina over Business Central in België legt de lokale context uit.

Wie nog niet weet of er maatwerk nodig is, begint beter met een scherp implementatietraject voor Business Central. Een goede analyse toont vaak dat het merendeel van de wensen zonder code kan, en geeft een eerlijk beeld van wat overblijft.

Een zakelijke aanpak in vijf stappen

  1. Beschrijf het probleem in woorden van de gebruiker, niet als oplossing.
  2. Controleer de standaard: instellingen, rollen, Designer, bestaande modules.
  3. Zoek een extensie op Microsoft Marketplace en toets onderhoud en Belgische dekking.
  4. Laat enkel het verschil bouwen, in een sandbox, met een functionele beschrijving.
  5. Plan het onderhoud: wie test bij elke update, wie past aan, wie beslist.

Zo blijft maatwerk een beheerste keuze in plaats van een verrassing. Wilt u vergelijken met een partij die dit traject begeleidt, dan stelt ERP Integrator u gratis voor aan een integrator die bij uw project past. De integrator voert het project uit; wij leggen alleen het contact.

Veelgestelde vragen

Kan ik Business Central aanpassen zonder te programmeren?

Ja, voor een groot deel. Veel aanpassingen zijn gewoon instellingen: velden en pagina's per gebruikersrol, goedkeuringsworkflows, nummerreeksen en rapportindelingen. Met de Designer in de client kunt u bovendien pagina's aanpassen via slepen en neerzetten. Programmeerwerk is pas nodig wanneer een proces echt niet in de standaard past.

In welke taal wordt maatwerk voor Business Central ontwikkeld?

Extensies worden geschreven in AL, meestal in Visual Studio Code. U voegt tabellen, pagina's, codeunits en rapporten toe of breidt ze uit, zonder de basiscode van Microsoft te wijzigen. Het resultaat is een .app-bestand dat u publiceert in een omgeving, eerst in een sandbox en daarna in productie.

Blokkeert maatwerk de updates van Business Central?

Een goed gebouwde extensie niet, want ze raakt de standaardcode niet aan en haakt in via uitbreidingen en events. Problemen ontstaan bij slordige afhankelijkheden, ontbrekende tests of onderhoud dat nooit wordt ingepland. Laat daarom bij elke update de extensies in een sandbox testen voordat de productieomgeving volgt.

Wat is het verschil tussen een extensie en een koppeling?

Een extensie voegt functies toe binnen Business Central zelf. Een koppeling verbindt de ERP met een andere toepassing, bijvoorbeeld een webshop, via de API of OData. Beide kunnen elkaar nodig hebben: een koppeling vraagt soms een aangepaste API-pagina, en die bouwt u dan als extensie.

Hoe beoordeel ik of een Business Central-developer betrouwbaar is?

Vraag hoe de partij omgaat met sandbox-tests, versiebeheer en documentatie, en laat een eerdere extensie uitleggen op functioneel niveau, zonder klantnamen. Een goede developer vraagt eerst naar uw proces en stelt vaak een standaardoplossing voor. Wie meteen code aanbiedt, heeft uw probleem nog niet begrepen.

Bronnen

  1. Microsoft Learn – Overview of development in Business Central
  2. Microsoft Learn – Business Central environments in the admin center
  3. Microsoft Learn – Business Central API v2.0
  4. Microsoft Learn – Operational limits for Business Central online
  5. Microsoft Learn – Shopify connector overview
  6. Microsoft Learn – About localization

De genoemde softwarenamen zijn handelsmerken van hun respectievelijke eigenaren en worden uitsluitend ter informatie vermeld. Deze site is onafhankelijk en niet verbonden aan een softwareleverancier.