Skip to main content

ACF Connector Specification — Microsoft Dynamics 365 Business Central

1. Purpose​

This specification defines how the ZAYAZ Accounting Connectivity Framework (ACF) integrates with Microsoft Dynamics 365 Business Central.

Business Central is treated as a cloud ERP and accounting platform rather than as an import/export format.

The preferred ZAYAZ architecture uses:

  • Microsoft Standard API v2.0;
  • Microsoft Entra ID service-to-service authentication;
  • Business Central permission sets;
  • custom AL APIs where the standard API does not expose required customer data;
  • Business Central webhooks for near-real-time change detection;
  • lastModifiedDateTime filtering for incremental retrieval where supported;
  • periodic authoritative reconciliation; and
  • TrustGate for source and transformation lineage.

The connector enables Business Central data to participate safely in:

  • ESG screening;
  • spend-based emissions;
  • supplier analysis;
  • procurement analysis;
  • physical activity discovery;
  • inventory and material-flow analysis;
  • project allocation;
  • asset analysis;
  • evidence collection;
  • VSME and ESRS prepopulation;
  • audit and assurance; and
  • continuous sustainability bookkeeping.

2. Source identity​

Business Central has a particularly clean multi-level source identity.

Microsoft Entra tenant
        ↓
Business Central environment
        ↓
Business Central company
        ↓
Business object
        ↓
Source record

ACF preserves all relevant levels.

The source identity therefore cannot be reduced to:

company name

or even:

company GUID

without environment and tenant context.

3. Environments​

A Microsoft Entra tenant can contain multiple Business Central environments.

Typical environment types include:

PRODUCTION
SANDBOX

The environment name forms part of the API path.

ZAYAZ must discover environments rather than assume:

environment = production

for every connection.

4. Company context​

Each Business Central environment can contain multiple companies.

Most business-data API routes are company-scoped.

For example:

environment
   ↓
companies
   ↓
company GUID
   ↓
generalLedgerEntries

Every company must map to:

ZAYAZ organization
      +
E-C-O Number

before processing.

5. Company is the ACF entity boundary​

For Business Central, company GUID becomes the primary ERP organizational partition.

Conceptually:

Business Central company
        ↓
legal entity assessment
        ↓
ZAYAZ organization
        ↓
E-C-O Number

The legal-entity relationship must still be validated rather than assumed blindly.

6. Standard API v2.0​

Microsoft Standard API v2.0 is the preferred connector surface.

The standard endpoint follows the Business Central environment and company model.

Conceptually:

api.businesscentral.dynamics.com
         ↓
tenant / environment
         ↓
api/v2.0
         ↓
company
         ↓
resource

The API stack is enabled by default in Business Central Online.

7. Why API v2.0 is preferred​

Microsoft explicitly recommends the REST API stack for integrations.

The standard API has several advantages:

  • stable integration contract;
  • GUID source identities;
  • OData v4 semantics;
  • filtering;
  • pagination;
  • relationships;
  • webhooks for supported entities;
  • predictable versioning; and
  • compatibility across Business Central Online environments.

ACF therefore treats it as the authoritative default integration surface.

8. Service-to-service authentication​

Production ZAYAZ integrations should use Microsoft Entra service-to-service authentication.

The OAuth model is:

Microsoft Entra application
        ↓
client credentials
        ↓
access token
        ↓
Business Central

This allows unattended integrations without an interactive user session.

9. Entra application permission​

The Microsoft Entra application requires Business Central API access.

For API and web-service access, Business Central documents:

API.ReadWrite.All

as the application-level permission.

That permission does not mean ZAYAZ should receive unrestricted Business Central object access.

10. Business Central permission sets​

A second authorization layer exists inside Business Central.

The application is registered on the:

Microsoft Entra applications

page.

Business Central permission sets are then assigned to the application.

This is where ZAYAZ should enforce least privilege.

11. SUPER is prohibited​

Business Central explicitly prevents Microsoft Entra applications from receiving the SUPER permission set.

This aligns well with ACF.

The connector should receive only the permissions needed for its approved source domains.

For example:

Read G/L entries
Read vendors
Read purchase invoices
Read items
Read dimensions

rather than:

full Business Central administration

12. ZAYAZ write control​

Many Business Central APIs also support:

  • POST;
  • PATCH;
  • DELETE; and
  • bound business actions.

ZAYAZ should therefore enforce:

READ = allowed by connector profile

WRITE = blocked by default

even when the application technically possesses the ability to perform write operations.

13. API endpoint structure​

Business Central API identity has several components:

Base URL
   +
Entra tenant / environment
   +
API route
   +
company
   +
resource

Custom APIs additionally add:

publisher
group
version

These values belong in lineage for custom source interfaces.

14. Environment discovery​

Business Central provides an endpoint for discovering tenant environments.

ACF can use this during onboarding to establish:

  • environment name;
  • environment type;
  • Entra tenant ID;
  • country code;
  • web-service URL; and
  • application family.

This means the onboarding flow can be largely machine-driven.

15. Connector profile​

Each connection produces:

ACF-BUSINESS-CENTRAL-CUSTOMER-PROFILE

containing:

  • Entra tenant ID;
  • environment;
  • company;
  • company mapping;
  • permissions;
  • standard API capabilities;
  • custom APIs;
  • webhook resources;
  • extension versions;
  • dimension mappings;
  • inventory capability; and
  • evidence capability.

16. Custom APIs​

Business Central provides strong AL-based API extensibility.

Where Microsoft Standard API v2.0 does not expose required data, the correct design is generally:

Business Central table / logic
        ↓
AL custom API
        ↓
versioned source contract
        ↓
ZAYAZ

rather than accessing internal database tables.

17. Custom API identity​

Custom API pages define:

APIPublisher
APIGroup
APIVersion
EntityName
EntitySetName

These become part of the endpoint contract.

ACF should register them explicitly.

18. Standard API pages cannot simply be extended​

Business Central does not currently support adding fields directly to Microsoft standard API pages or queries using ordinary API-page extensions.

If ZAYAZ needs additional fields:

standard API
    +
extra customer field

the correct pattern is:

new custom API

with a separately versioned contract.

19. API pages​

Custom API pages are intended specifically for integration.

They support:

  • REST;
  • OData v4;
  • CRUD where implemented;
  • versioning; and
  • webhooks where the source structure qualifies.

This makes API pages the preferred customer-specific source interface.

20. API queries​

API queries are useful for optimized read models.

For example:

G/L entry
  +
vendor
  +
dimension
  +
custom field
       ↓
read-only API query

could reduce source round trips.

However, API queries do not have the same webhook support as API pages.

21. OData web services​

Business Central also supports publishing pages and queries as OData v4 web services.

These remain useful for:

  • existing customer integrations;
  • compatibility;
  • specialized source views.

But new ZAYAZ development should prefer API pages and queries.

22. SOAP​

SOAP is a legacy path.

The architecture should be:

SOAP
  ↓ migration
API / OData v4

New ZAYAZ implementations must not create new SOAP dependencies.

23. SOAP removal​

Microsoft has already deprecated SOAP web-service publication of Microsoft UI pages.

Support for exposing Microsoft UI pages through SOAP is scheduled for removal in Business Central version 29.0.

That makes API-first design especially important.

24. Webhooks​

Business Central has native webhook support.

A subscription identifies a resource such as:

companies(companyId)/customers

and a ZAYAZ notification URL.

Business Central then sends notifications when supported source entities change.

25. Subscription handshake​

Webhook creation requires a handshake.

Business Central sends a:

validationToken

to the notification endpoint.

ZAYAZ must return the token with a successful response before the subscription becomes active.

The same handshake occurs during renewal.

26. Webhook client state​

Subscriptions can contain:

clientState

which is returned in notifications.

ZAYAZ should use this as an opaque shared verification value.

This strengthens notification integrity.

27. Subscription expiry​

Webhook subscriptions expire unless renewed.

The default lifetime is three days.

API Hub must therefore operate a subscription-renewal scheduler.

The lifecycle is:

create
  ↓
active
  ↓
renew
  ↓
active

not:

create once
  ↓
forget forever

28. Webhook supported resources​

Webhook capability should be discovered dynamically.

Business Central exposes information about which API resources support webhook subscriptions.

The documented standard resources include important domains such as:

  • accounts;
  • customers;
  • vendors;
  • general ledger entries;
  • items;
  • purchase invoices;
  • sales invoices;
  • sales orders;
  • dimensions;
  • journals;
  • employees; and
  • units of measure.

ACF must not assume that every standard or custom resource supports webhooks.

29. Webhook change types​

Business Central can emit:

created
updated
deleted
collection

notifications.

A collection event means many records changed and ZAYAZ should perform a filtered authoritative reread.

30. Notification delay​

Webhooks are intentionally not instantaneous.

Business Central normally waits approximately 30 seconds after the first source change before issuing the notification.

Multiple changes during that interval may therefore be coalesced.

This is useful because it avoids excessive event noise.

31. Collection events​

If more than roughly 1,000 records change during the notification delay window, Business Central can issue a single:

collection

notification.

ZAYAZ must therefore understand that:

one event

can mean:

many changed records

and trigger a source query accordingly.

32. Webhook retries​

If Business Central cannot reach the subscriber, eligible failures are retried over a period of approximately 36 hours.

ZAYAZ should expect retries following conditions such as:

  • timeout;
  • throttling; and
  • server-side failure.

Webhook consumers must therefore be idempotent.

33. Webhook deletion risk​

Not every HTTP failure response triggers retry.

Some unsupported failure responses can cause the subscription to be deleted.

DaVE should therefore treat:

subscription disappeared

as a material source-integrity condition.

34. Subscription monitoring​

API Hub should continuously track:

subscription ID
resource
company
expiration
notification URL
client state
last successful notification
last renewal

and alert before expiration.

35. Delegated-admin caveat​

Business Central webhook behavior has edge cases around changes made through delegated administration.

This reinforces an important ACF principle:

Webhooks improve freshness; reconciliation proves completeness.

36. Reconciliation​

Every production connector should periodically compare its local source state with Business Central.

The pattern is:

Initial sync
     ↓
Webhooks
     ↓
Incremental API reads
     ↓
Periodic reconciliation

No single event stream should be treated as the complete accounting ledger.

37. lastModifiedDateTime​

Many Business Central API resources expose:

lastModifiedDateTime

This is extremely useful for incremental retrieval.

A typical fallback strategy is:

last successful timestamp
      ↓
overlap window
      ↓
$filter lastModifiedDateTime gt X
      ↓
pagination
      ↓
deduplication
      ↓
new watermark

38. Pagination​

Large resource collections are paginated.

ZAYAZ must follow continuation links/tokens rather than assuming the first page contains the complete source population.

Pagination state belongs to ingestion telemetry.

39. Source filtering​

Business Central supports OData filtering.

ACF should use filtering aggressively to minimize:

  • network traffic;
  • API consumption;
  • memory;
  • data exposure; and
  • reconciliation cost.

For example:

all general ledger entries

should not be retrieved when:

general ledger entries changed since watermark

is sufficient.

40. API limits​

Business Central Online applies operational limits to maintain service stability.

The connector must be designed for:

  • throttling;
  • queued requests;
  • transient service unavailability;
  • long-request timeout; and
  • concurrent request limits.

A 429 is an operational signal, not a fatal data error.

41. Adaptive throttling​

API Hub should react to pressure:

normal
  ↓
parallel requests
  ↓
429 / 503?
   │
 ┌─┴─┐
no   yes
│     │
▼     ▼
continue
      reduce concurrency
      +
      backoff
      +
      jitter

This behavior should be shared across all ACF SaaS connectors.

42. General ledger​

Business Central exposes general ledger entries directly through API v2.0.

Useful source fields include:

  • posting date;
  • document number;
  • document type;
  • account;
  • description;
  • debit amount;
  • credit amount;
  • dimensions;
  • attachments; and
  • last-modified timestamp.

This makes Business Central immediately useful for DQ1 screening.

43. General-ledger source identity​

A general ledger entry has a GUID source identity plus entry number and contextual information.

ZAYAZ should preserve both machine source identity and human-readable accounting identifiers where available.

44. General-ledger ESG use​

The G/L can support:

financial posting
      ↓
account classification
      ↓
vendor / dimension enrichment
      ↓
spend category
      ↓
factor
      ↓
tCO2e

This is accounting-based estimation.

It should not be confused with physical activity.

45. Vendors​

Business Central vendor records provide supplier identity.

They can support:

  • supplier spend;
  • country enrichment;
  • supplier questionnaires;
  • Scope 3;
  • due diligence;
  • supplier-specific factor lookup; and
  • evidence collection.

Vendor identity alone does not constitute supplier ESG data.

46. Purchase invoices​

Purchase invoices materially improve ESG context.

Business Central API resources can expose relationships to:

  • vendor;
  • currency;
  • dimensions;
  • purchase-invoice lines;
  • PDFs; and
  • attachments.

This creates a strong DQ2 source layer.

47. Source invoice chain​

A typical evidence chain can be:

G/L entry
   ↓
Purchase invoice
   ↓
Purchase invoice line
   ↓
Vendor
   ↓
Item
   ↓
Attachment / PDF

Each layer can improve classification or evidence quality.

48. Purchase orders​

Business Central exposes purchase orders and purchase-order lines.

Relevant information can include:

  • vendor;
  • order date;
  • currency;
  • requested receipt date;
  • item or account line;
  • quantity;
  • price;
  • dimensions; and
  • attachments.

This can provide ESG information before final invoicing.

49. Purchase receipts​

Purchase receipts are especially valuable.

They indicate what was actually received rather than merely what was ordered.

Purchase Order
100 units ordered
       ↓
Purchase Receipt
92 units received

For some sustainability calculations the received quantity is the stronger activity signal.

50. Purchase receipt lines​

Receipt lines can expose:

  • line type;
  • item/account identity;
  • description;
  • unit of measure;
  • quantity;
  • unit cost; and
  • dimensional context.

This provides a promising bridge between accounting and physical activity.

51. Line types matter​

A purchase receipt line may represent different source concepts.

For example:

Item
G/L Account
Resource
Fixed Asset
Charge Item

A quantity on an Item line has different semantics from a quantity associated with another line type.

ACF must preserve that distinction.

52. Items​

Business Central item master data can distinguish source types such as:

Inventory
Service
Non-Inventory

Items also have relationships to:

  • item categories;
  • posting groups;
  • units of measure;
  • variants;
  • dimensions; and
  • attachments.

This provides a strong semantic anchor for ESG classification.

53. Item identity​

A Business Central item number can become a canonical bridge between:

procurement
inventory
sales
product footprint
supplier evidence

but the item number itself is not an environmental declaration.

54. Item categories​

Item categories can provide reusable classification signals.

For example:

Item
  +
Item Category
  +
Vendor
  +
Receipt Quantity
       ↓
ZAYAZ material classification

This may be considerably stronger than account classification.

55. Item ledger entries​

The standard API now exposes item ledger entries.

This is strategically important for ACF.

An item ledger entry can contain:

  • item;
  • posting date;
  • entry type;
  • source;
  • document;
  • description;
  • quantity;
  • actual sales amount;
  • actual cost amount; and
  • last-modified timestamp.

56. Inventory activity​

Item ledger entries give ACF a route toward physical inventory activity.

Item Ledger Entry
       ↓
item
       ↓
entry type
       ↓
quantity
       ↓
unit semantics
       ↓
activity interpretation

This can support DQ3 in appropriate cases.

57. Physical quantity is not enough​

Suppose Business Central records:

quantity = 250

That alone is insufficient.

ZAYAZ must also determine:

250 what?
which item?
which entry type?
which direction?
which unit?
what business activity?

before selecting a factor.

58. Units of measure​

Business Central provides a dedicated Unit of Measure API.

Useful fields include:

  • code;
  • display name;
  • symbol; and
  • international standard code.

The international standard code can use UNECE Recommendation 20 semantics.

This is unusually useful for ESG interoperability.

59. Standardized unit resolution​

A source unit such as:

KG

can potentially resolve through:

Business Central unit
      ↓
international standard code
      ↓
ZAYAZ unit registry
      ↓
canonical kg

which greatly reduces ambiguity.

60. Semantic Activity Resolver​

Business Central reinforces the activity-resolution architecture we identified with e-conomic and SAP:

SOURCE RECORD
      ↓
QUANTITY
      ↓
UNIT
      ↓
ITEM / ACTIVITY
      ↓
TRANSACTION TYPE
      ↓
DIMENSION / LOCATION
      ↓
METHOD COMPATIBILITY
      ↓
FACTOR ELIGIBILITY

Only then should quantity enter MICE as environmental activity.

61. Example — purchased material​

Suppose Business Central provides:

Vendor: Steel Supplier A
Item: STEEL-HRC
Receipt quantity: 18,500
Unit: KG

After semantic validation:

18,500 kg steel received
       ↓
supplier
       ↓
material classification
       ↓
appropriate factor
       ↓
tCO2e

could support a much higher-quality result than monetary spend alone.

62. Example — unsafe interpretation​

Suppose instead:

Item: CONSULTING-PACKAGE
Quantity: 1
Unit: EA

ZAYAZ must not convert:

1 EA

into a physical environmental quantity.

The source remains primarily financial/service context unless an approved methodology says otherwise.

63. Dimensions​

Business Central dimensions are powerful customer-defined accounting structures.

They may represent:

  • department;
  • business unit;
  • region;
  • project;
  • customer segment;
  • product group;
  • facility;
  • cost center; or
  • another customer-defined concept.

Their meaning must be resolved.

64. Dimension sets​

Dimension Set Lines can be attached to multiple source objects, including:

  • general-ledger entries;
  • purchase invoices;
  • purchase-invoice lines;
  • sales documents;
  • journal lines; and
  • time registrations.

This means a single semantic dimension model can enrich many ACF source domains.

65. Dimension mapping​

A mapping can look like:

Business Central dimension
SITE = OSLO
      ↓
ZAYAZ dimension map
      ↓
Facility: Oslo
      ↓
Norway
      ↓
location-sensitive ESG context

The mapping must be versioned.

66. Fixed assets​

Business Central exposes fixed assets through the standard API.

The resource can contain information such as:

  • asset number;
  • display name;
  • location;
  • class;
  • subclass;
  • serial number;
  • employee;
  • acquisition date;
  • acquisition cost;
  • depreciation; and
  • book value.

This is valuable for capital-goods and physical-asset analysis.

67. Asset ESG opportunities​

Fixed assets can help identify:

vehicles
machinery
equipment
facilities
IT assets
other capital goods

Environmental characteristics may still require enrichment.

For example:

Company Vehicle

does not establish:

fuel type
annual distance
vehicle efficiency

without additional source data.

68. Projects​

Business Central exposes project identities through the standard API.

This supports:

  • project emissions;
  • construction;
  • customer engagements;
  • project procurement;
  • project travel;
  • project financial allocation; and
  • project sustainability reporting.

69. Project evidence​

Projects can also link to:

  • documents;
  • PDFs; and
  • custom API data.

This allows the project object to become a strong evidence aggregation key.

70. Time registration​

Business Central time registration entries can contain:

  • employee;
  • project;
  • project task;
  • date;
  • quantity;
  • unit of measure; and
  • status.

This is useful for service businesses.

71. Time allocation​

For professional-services emissions:

project time
     ↓
project allocation
     ↓
office / travel / service overhead
     ↓
approved allocation method

may be useful.

Hours should not automatically be converted directly to emissions.

72. Attachments​

Business Central supports source attachments.

An attachment is linked to a parent source object.

Potential parents include:

  • general ledger entry;
  • journal;
  • purchase invoice;
  • purchase order;
  • sales invoice; and
  • other supported documents.

This is highly valuable for TrustGate.

73. PDF documents​

Business Central can also expose generated PDF documents associated with transactional objects.

Potential examples include:

  • sales invoice;
  • purchase invoice;
  • purchase order;
  • project; and
  • credit memo.

These can form part of the auditor-readable evidence package.

74. Document evidence chain​

A sustainability result can therefore resolve:

ESRS / VSME datapoint
      ↓
ZAYAZ ESG result
      ↓
MICE execution
      ↓
validated activity
      ↓
Business Central receipt / invoice
      ↓
source line
      ↓
attachment / PDF
      ↓
vendor / item

That is a strong evidence architecture.

75. Documents as enrichment​

An accounting API may contain:

Amount: EUR 12,000
Vendor: Energy Company

while the attachment may contain:

Consumption: 42,600 kWh
Meter: ABC123
Period: January

The accounting object can therefore function as a locator for better ESG evidence.

76. Data-quality hierarchy​

ACF applies the common quality ladder.

ACF-DQ1 — Accounting-only estimate​

Typical Business Central input:

  • G/L account;
  • G/L entry;
  • vendor;
  • financial amount.

ACF-DQ2 — Invoice/procurement-level data​

Typical input:

  • purchase invoice;
  • invoice line;
  • purchase order;
  • purchase receipt;
  • item;
  • source document.

ACF-DQ3 — Activity data​

Typical input:

  • validated purchase receipt quantity;
  • validated item-ledger quantity;
  • other physical source quantity with canonical unit.

ACF-DQ4 — Supplier/item-specific data​

Primary information attributable to the actual:

  • supplier;
  • item;
  • product;
  • service; or
  • activity.

ACF-DQ5 — Verified primary data​

The primary information has passed the applicable verification process.

77. Quality progression​

Business Central can therefore support:

G/L spend
   DQ1
    ↓
Purchase invoice
   DQ2
    ↓
Purchase receipt + item
   DQ2/DQ3
    ↓
Physical quantity
   DQ3
    ↓
Supplier-specific data
   DQ4
    ↓
Verified primary
   DQ5

The full history remains in TrustGate.

78. Spend-based emissions​

A spend-based calculation may use:

G/L account
   +
vendor
   +
purchase invoice
   +
item
   +
dimension
   +
project
      ↓
classification
      ↓
spend normalization
      ↓
factor
      ↓
tCO2e

This should be substantially stronger than account-only screening.

79. Activity-based emissions​

Where appropriate physical quantities exist:

Purchase Receipt
       ↓
Receipt Line
       ↓
Item
       ↓
Quantity
       ↓
Unit of Measure
       ↓
validated semantic
       ↓
factor
       ↓
tCO2e

can replace or supersede a spend-based estimate.

80. Circularity​

The combination of:

  • items;
  • item categories;
  • item ledger entries;
  • purchase receipts;
  • quantities; and
  • custom material classification

creates future circularity opportunities.

Potential flows include:

purchased item
received quantity
inventory movement
sold quantity
returned quantity
waste/reuse classification

where the source configuration provides sufficient semantics.

81. PEF/LCA opportunity​

Business Central can also provide useful source inputs for product environmental modeling:

  • item;
  • item category;
  • vendor;
  • physical quantity;
  • unit;
  • receipt;
  • inventory flow;
  • project; and
  • dimensions.

This is not as manufacturing-rich as SAP, but for many SMEs it may be enough to anchor product-level activity.

82. Custom sustainability fields​

Some customers may already maintain information such as:

  • material type;
  • product weight;
  • facility;
  • supplier category;
  • fuel type;
  • vehicle type;
  • environmental product declaration reference; or
  • sustainability classification

inside extensions.

Rather than scraping those extensions, ZAYAZ should expose them through a governed custom AL API.

83. Custom ESG API example​

A customer extension could expose:

itemId
materialType
weightKg
supplierCountry
epdReference
facilityCode

through:

api/zayaz/esg/v1.0

This becomes a versioned source contract.

84. Custom API lineage​

TrustGate must then preserve:

extension ID
extension version
API publisher
API group
API version
source entity
source ID

so that the custom data remains fully auditable.

85. Custom API versus direct table access​

This is a very important ACF rule.

If a Business Central extension stores an ESG-relevant value:

custom table field

ZAYAZ should not create a hidden dependency on that table.

Instead:

custom table
      ↓
custom API contract
      ↓
ZAYAZ

This protects both applications from schema coupling.

86. Multi-company operations​

One Business Central environment may contain many companies.

API Hub should therefore be able to synchronize:

Environment A
    │
    ├── Company 1 → E-C-O 1
    ├── Company 2 → E-C-O 2
    └── Company 3 → E-C-O 3

without creating separate connector code for each company.

87. Group reporting​

Group ESG calculations can then aggregate:

Company A
Company B
Company C

according to the applicable ZAYAZ reporting boundary.

Business Central company structure does not itself determine the final sustainability consolidation perimeter.

88. Accounting-partner model​

Business Central also maps well to accounting-partner use cases.

A partner may administer several customer tenants/environments.

ACF identity must nevertheless remain:

customer Entra tenant
     +
environment
     +
company
     +
E-C-O Number

rather than:

accounting firm

as the data boundary.

89. Environment isolation​

Sandbox and production must never share source identity accidentally.

For example:

Production / Company A

and:

Sandbox / Company A

are different source contexts even if the displayed company name is identical.

90. Data minimization​

Business Central may contain far more information than ZAYAZ needs.

A Scope 3 screening workflow requiring:

vendor
G/L account
amount
currency
item
dimension

does not justify automatically retrieving:

all employee data
all customer addresses
all project documents
all fixed assets

ACF retrieves by purpose.

91. Source-side efficiency​

API Hub should prefer:

$filter
pagination
$expand where useful
batching where appropriate
lastModifiedDateTime
webhooks

over repeated full scans.

This is both a performance and governance requirement.

92. Webhook renewal architecture​

Subscription renewal is operationally important enough to deserve its own service behavior:

Subscription registry
       ↓
expiration monitor
       ↓
renewal window
       ↓
handshake
       ↓
renewed subscription

If renewal fails:

DaVE alert
   +
API reconciliation

should occur.

93. Collection notification recovery​

When Business Central emits:

changeType = collection

ZAYAZ should not attempt to infer which records changed from the event itself.

Instead:

collection event
      ↓
resource
      ↓
filtered authoritative query
      ↓
changed records

This is another reusable ACF event pattern.

94. Historical mutation​

A posted accounting source may later be affected by:

  • correction;
  • credit memo;
  • reversal;
  • updated dimension;
  • updated attachment;
  • changed master data; or
  • another accounting adjustment.

A material historical change produces:

source mutation
      ↓
DaVE
      ↓
TrustGate lineage event
      ↓
affected ESG result
      ↓
revalidation

95. ZARA behavior​

ZARA can use the Business Central profile to explain:

  • which environment supplied a value;
  • which company owns the record;
  • whether the source was standard or custom API;
  • which vendor and item were involved;
  • what dimensions applied;
  • whether a quantity qualifies as activity data;
  • which attachment supports the value;
  • why a calculation changed;
  • what quality level applies; and
  • what evidence remains missing.

96. ZARA source distinction​

ZARA must distinguish:

Microsoft standard API source

Customer custom API source

Business Central accounting value

ZAYAZ-normalized value

ZAYAZ classification

ZAYAZ ESG calculation

External enrichment

These are different provenance classes.

97. FOGE behavior​

FOGE uses ACF to determine:

  • source availability;
  • company scope;
  • field authority;
  • evidence quality;
  • source preference;
  • dimension mapping;
  • calculation state; and
  • missing evidence.

A Business Central field does not automatically equal a reporting datapoint.

98. MICE behavior​

MICE receives governed inputs such as:

  • Business Central tenant;
  • environment;
  • company;
  • source record;
  • item;
  • vendor;
  • quantity;
  • unit;
  • amount;
  • currency;
  • dimensions;
  • classification;
  • method;
  • emission factor;
  • factor vintage;
  • reporting period; and
  • quality tier.

This supports deterministic reproduction.

99. COSE behavior​

COSE can evaluate:

Requirement:
physical energy quantity

against:

Business Central:
utility invoice amount only

and return:

activity evidence gap

rather than silently constructing a physical value.

100. DaVE behavior​

DaVE monitors:

  • authentication;
  • permissions;
  • environments;
  • companies;
  • API throttling;
  • webhook expiration;
  • subscription deletion;
  • custom API drift;
  • extension drift;
  • source reconciliation;
  • dimension mapping;
  • unit mapping;
  • supplier resolution; and
  • unexpected historical change.

101. TrustGate behavior​

TrustGate preserves:

Business Central
      ↓
tenant / environment / company
      ↓
standard or custom API
      ↓
source record
      ↓
attachment / PDF
      ↓
canonical mapping
      ↓
classification
      ↓
activity resolution
      ↓
MICE
      ↓
reporting output
      ↓
verification
             MICROSOFT ENTRA ID
                     │
                OAuth 2.0 S2S
                     │
                     ▼
           BUSINESS CENTRAL ONLINE
                     │
           ┌─────────┴─────────┐
           │                   │
      Standard API v2       Webhooks
           │                   │
      Custom APIs              │
       if required             │
           └─────────┬─────────┘
                     ▼
                ZAYAZ API HUB
                     │
          tenant/environment/company
                     │
                     ▼
                 TRUSTGATE
                     │
                     ▼
                    ACF
          ┌──────────┼──────────┐
          │          │          │
       normalize  validate   classify
          │          │          │
          └──────────┼──────────┘
                     ▼
             CANONICAL DATA MODEL
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
         MICE       FOGE       ZARA
          │          │          │
          └──────────┼──────────┘
                     ▼
              GOVERNED ESG DATA

Periodic authoritative reconciliation runs alongside the event path.

103. Quick-start implementation​

A controlled pilot should:

  1. register a Microsoft Entra application;
  2. grant Business Central API application permission;
  3. register the application in Business Central;
  4. assign minimum permission sets;
  5. obtain an S2S access token;
  6. discover environments;
  7. select the test/sandbox environment;
  8. retrieve companies;
  9. map the test company to ZAYAZ;
  10. generate the customer connector profile;
  11. ingest G/L entries;
  12. ingest vendors and purchase invoices;
  13. ingest items and purchase receipts;
  14. validate units of measure;
  15. inspect dimensions;
  16. test attachments and PDFs;
  17. perform initial ESG screening;
  18. configure webhooks;
  19. test webhook renewal;
  20. test collection event recovery;
  21. test API throttling behavior;
  22. run source reconciliation; and
  23. verify TrustGate lineage.

104. Production implementation​

Production should add:

  • production Entra consent;
  • least-privilege Business Central permission sets;
  • production environment mapping;
  • complete company mapping;
  • E-C-O Number mapping;
  • durable webhook subscriptions;
  • subscription renewal;
  • periodic reconciliation;
  • adaptive rate control;
  • custom API governance;
  • extension drift monitoring;
  • attachment evidence;
  • dimension mappings;
  • item/unit semantic mappings;
  • activity-data validation;
  • TrustGate registration;
  • DaVE monitoring; and
  • governed recalculation.

105. Inventory-enriched implementation​

For customers with meaningful item/inventory use, ZAYAZ should additionally ingest:

Items
     +
Units of Measure
     +
Purchase Receipts
     +
Item Ledger Entries

This enables:

financial activity
      ↓
item activity
      ↓
physical quantity
      ↓
material flow

which may provide a major data-quality improvement.

106. Custom-extension implementation​

Where customer extensions contain important ESG-relevant information:

  1. identify the source extension;
  2. identify the relevant data;
  3. create or validate a custom API;
  4. version the API;
  5. assign least-privilege permissions;
  6. register its schema;
  7. map its fields;
  8. register it with TrustGate; and
  9. monitor extension/API version changes.

The custom interface becomes an explicit governed source.

107. On-premises implementation​

For Business Central on-premises, ACF should first determine:

  • application version;
  • server instance;
  • API enablement;
  • authentication model;
  • network topology;
  • custom extensions;
  • existing OData services; and
  • legacy SOAP dependencies.

The target architecture remains:

API / custom API / OData v4

rather than new SOAP or direct-database integration.

108. Hybrid ESG implementation​

The strongest sustainability result may combine:

Business Central
   │
   ├── vendor
   ├── invoice
   ├── item
   ├── receipt
   ├── quantity
   └── project
        +
attachment
        +
supplier portal
        +
meter data
        +
logistics data
        +
LCA data
        ↓
governed ESG result

Business Central becomes the financial and operational backbone while ZAYAZ orchestrates the evidence hierarchy.

109. Limitations​

109.1 Standard API coverage is not complete​

Customer-specific fields may require a custom AL API.

109.2 Standard APIs cannot simply be extended​

A separate custom API contract is required.

109.3 Permission sets affect data visibility​

Unavailable data may reflect authorization rather than true source absence.

109.4 Environments and companies are separate identities​

Names alone cannot define source identity.

109.5 Webhooks expire​

Subscriptions require continuous renewal.

109.6 Webhooks can be lost or deleted​

Reconciliation remains mandatory.

109.7 Not every resource supports webhook subscriptions​

Coverage must be discovered.

109.8 API limits require adaptive client behavior​

Throttling and transient errors are normal operational conditions.

109.9 Quantity does not automatically equal ESG activity​

Source semantics must be validated.

109.10 Items are not environmental declarations​

Additional product or supplier evidence may be required.

109.11 Accounting data cannot satisfy every sustainability disclosure​

Policies, governance, workforce and narrative requirements require other evidence.

110. Connector activation gate​

A production Business Central connector should not activate until:

Microsoft Entra application          PASS
S2S authentication                   PASS
Business Central application record  PASS
Permission sets                      PASS
Environment identity                 PASS
Company identity                     PASS
ZAYAZ organization mapping           PASS
E-C-O Number mapping                 PASS
Standard API profile                 PASS
Custom API profile                   PASS / N/A
Canonical mapping                    PASS
TrustGate registration               PASS
Initial reconciliation               PASS
API throttling controls              PASS
Monitoring                           PASS

For webhook-enabled production:

Supported-resource discovery         PASS
Subscription creation                PASS
Handshake                            PASS
Client-state validation              PASS
Renewal scheduler                    PASS
Collection-event handling            PASS
Recovery / reconciliation            PASS

must also pass.

111. Definition of done​

The Business Central connector is production-ready when ZAYAZ can demonstrate that it can:

  1. authenticate through Microsoft Entra ID;
  2. operate unattended through S2S authentication;
  3. register the application in Business Central;
  4. enforce least-privilege permission sets;
  5. prevent unapproved write operations;
  6. discover Business Central environments;
  7. distinguish production and sandbox;
  8. discover companies;
  9. map companies to ZAYAZ organizations and E-C-O Numbers;
  10. use Standard API v2.0 as the default interface;
  11. identify standard-API gaps;
  12. govern custom AL APIs;
  13. record custom API publisher, group and version;
  14. retrieve general-ledger entries;
  15. retrieve vendors;
  16. retrieve purchase invoices;
  17. retrieve purchase orders;
  18. retrieve purchase receipts;
  19. retrieve items and item categories;
  20. retrieve item ledger entries;
  21. retrieve units of measure;
  22. resolve international unit codes where available;
  23. retrieve dimensions and dimension-set lines;
  24. retrieve fixed assets;
  25. retrieve projects;
  26. retrieve time-registration entries;
  27. retrieve attachments and PDF evidence;
  28. preserve source object relationships;
  29. use lastModifiedDateTime where appropriate;
  30. paginate source collections correctly;
  31. operate within Business Central operational limits;
  32. handle 429, 503 and 504 responses safely;
  33. create webhook subscriptions;
  34. perform subscription handshakes;
  35. renew subscriptions before expiration;
  36. detect lost or deleted subscriptions;
  37. process collection notifications;
  38. reread authoritative source state;
  39. reconcile webhook state against the API;
  40. map source records into the ZAYAZ canonical model;
  41. normalize and validate them deterministically;
  42. distinguish financial amounts from physical activity;
  43. promote validated receipt/item-ledger quantities to activity data;
  44. reject unresolved quantity semantics;
  45. perform ESG screening without inventing activity;
  46. upgrade calculations when higher-quality evidence becomes available;
  47. preserve prior calculations and provenance;
  48. support PEF/LCA and circularity where data quality permits;
  49. support ZARA, FOGE, MICE, COSE, DaVE and TrustGate;
  50. prevent cross-tenant, cross-environment and cross-company data leakage; and
  51. reproduce any material ESG result from Business Central source to final output.

112. Source references​

This connector specification is based primarily on current official Microsoft documentation covering:

  • Business Central integration architecture;
  • Business Central Standard API v2.0;
  • API endpoint structure;
  • Microsoft Entra ID authentication;
  • service-to-service authentication;
  • Business Central permission sets;
  • Business Central environments;
  • custom AL APIs;
  • API pages;
  • API queries;
  • OData web services;
  • SOAP deprecation;
  • webhook subscriptions;
  • API limits;
  • operational limits;
  • general ledger entries;
  • purchase invoices;
  • purchase orders;
  • purchase receipts;
  • items;
  • item ledger entries;
  • units of measure;
  • dimensions;
  • fixed assets;
  • projects;
  • time registration;
  • attachments; and
  • PDF documents.

The customer's actual Business Central environment, company configuration, installed extensions, permissions and API contracts remain authoritative for implementation.

The ACF customer connector profile must be reviewed or regenerated when material changes affect:

  • Microsoft Entra application identity;
  • Business Central environment;
  • Business Central company;
  • permissions;
  • Standard API behavior;
  • custom API versions;
  • installed extensions;
  • webhook support;
  • dimension configuration;
  • item configuration;
  • unit configuration;
  • custom source fields; or
  • canonical mappings.


Runtime Provider Extension​

The provider-specific runtime contract for this connector is maintained separately from the common ACF connector frontmatter.

It contains machine-actionable provider semantics that are intentionally not part of the common ACF schema, including authentication lifecycle, provider object revision semantics, change-capture constraints and provider-specific capability rules.

provider-extension.yamlGitHub ↗
schema_id: zayaz.acf.provider-extension.v1
extension_version: 1.0.0
connector_id: ACF-BUSINESS-CENTRAL
provider:
  namespace: microsoft.business_central
  name: Microsoft
  product: Dynamics 365 Business Central
runtime:
  source_contract:
    primary_api: standard_api_v2
    standard_api_version: v2.0
    protocol: rest_odata_v4
    custom_al_api_supported: true
    odata_v4_secondary_supported: true
    soap_new_integrations_preferred: false
  source_identity:
    tenant_field: microsoft_entra_tenant_id
    environment_field: environment_name
    organization_field: company_guid
  object_revision:
    modified_at_field: lastModifiedDateTime
  change_capture:
    webhook:
      supported: true
      handshake_required: true
      client_state_supported: true
      subscription_renewal_required: true
      default_subscription_lifetime_days: 3
      maximum_online_subscriptions: 200
      default_notification_delay_seconds: 30
      collection_notification_threshold: 1000
      retry_window_hours: 36
      authoritative_payload: false
    reconciliation:
      required: true
  capability_rules:
    standard_api_preferred: true
    customer_extension_preferred_when_standard_api_lacks_required_fields: true
    effective_authorization_requires_business_central_permission_sets: true
  source_semantics:
    unit_standard_field: internationalStandardCode
    item_ledger_quantity:
      activity_status: candidate
      requires_business_semantic_resolution: true
    dimensions:
      candidate_id_class: EBU
      automatic_resolution_allowed: false
    projects:
      candidate_id_class: EBP
      automatic_resolution_allowed: false
  evidence:
    attachments_supported: true
    pdf_documents_supported: true
  extensions:
    deployment:
      online_primary: true
      on_premises_supported: true
    authorization:
      broad_application_permission_is_not_effective_object_authorization: true
governance:
  status: active
  last_verified: 2026-08-30
  review_interval_days: 90
  change_control_required: true
  source_basis: connector_specification
GitHub RepoRequest for Change (RFC)
Last updated on by ZAYAZ