Business Central implementation case study
Inside the ERP-side work: mapping Business Central, building the AL extension, handling the required invoice flows, and verifying the connection against PINT AE rules and an ASP environment.
Customer ERP
Implementation layer
Accredited network
One customer connection
The work covered more than sending invoice data to an endpoint. It included the domain rules, Business Central extension, ASP interface, document lifecycle, inbound flow, operational behavior, and verification system.
For an ASP, this is the work between signing a customer and moving compliant invoices.
PINT AE rules, Business Central objects, tax treatment, and document decisions.
AL data model, setup, page extensions, posting events, and background processing.
Authentication, uploads, status handling, errors, and inbound documents.
XML rules, sandbox scenarios, negative cases, client behavior, and UAT criteria.
Value for the ASP
The ASP platform may be standard. The customer environment is not. Posting setup, tax configuration, extensions, invoice flows, and operating constraints vary by tenant.
Lab0 works from the actual environment, builds the ERP-side connection, exercises representative flows, and corrects what fails.
Division of labor
Implementation scope
The per-tenant AL extension covers outbound, self-billing, deemed-supply, and inbound flows, plus the behavior required to operate them inside Business Central.
A connector can generate valid XML for one sample invoice and still fail as an implementation. The edge cases sit in corrections, changing setup, background jobs, inbound conversion, and rejected documents.
Outbound
Self-billing
Special flow
Inbound
How the AI FDE operated
The AI FDE stayed inside the implementation cycle. It read the evidence, mapped the system, changed the implementation, exercised the flow, and corrected failures against the governing source or observed state.
Establish the governing rules and inspect the real ERP behavior.
Trace invoice data through records, posting setup, and extensions.
Implement setup, events, submissions, API paths, and background work.
Run representative flows and inspect what the system actually produced.
Resolve failures against source evidence, then rerun the right layer.
Technical architecture
Business Central remains the operational system. Filing is registered around its transactions, then handled through a separate submission lifecycle with explicit status and inbound paths.
BC transaction
Canonical data
PINT AE XML
ASP lifecycle
Status + inbound
Posting
Register filing work without making accounting depend on the network.
Queue
Send, refresh state, and keep terminal documents out of repeat polling.
Inbound staging
Keep the original payload even when accounting conversion fails.
Technical proof
The difficult parts are often small enough to miss in a broad architecture diagram. They are also where apparently complete integrations break.
01 · Document history
The implementation reads the original invoice type from stored submitted XML instead of recomputing it from configuration that may have changed later.
Filed history
Filed as 380
Stored in submitted XML
Inherits 381
Uses what was filed, not today’s setup
02 · Content assertions
Structural validation may prove an element exists without proving its value is right. The test system therefore asserts on business content emitted by AL.
Presence ≠ correctness
The element is present. Its value can still be wrong.
The implementation checks the business content that moved.
03 · System state
Business Central can ignore unknown or read-only fields while returning success. The harness reads records back and verifies the stored value.
Transport ≠ state
A successful response is only the start of the check.
Verification
Structural validity, business content, ERP behavior, and live network state are checked separately. That makes failures easier to locate and harder to wave through.
Rules and XML
ERP behavior
Operational UX
Network state
catalogue instances in the offline examiner design
commercial decision-tree cases in the sandbox plan
manual client behaviors defined for inspection
What the ASP gets
The human remains responsible for access, scope, and consequential architecture choices. The AI FDE supplies the execution capacity between those decisions: reading the system, changing the implementation, running the checks it can reach, and carrying corrected rules into the next customer.
Show us the ERP environment, the invoice flows, and the interface your ASP expects. We’ll map the implementation path and show you how a Lab0 AI FDE handles the work.