MYOB Advanced — Known Issues (Finance View)

Active workarounds, rec quirks, and behaviour that catches new users out. Append-only — when something is genuinely resolved, mark it resolved with a date rather than deleting it.

ALLOCATION ledger postings absent from PWG_DATA

Status: open. Reconciliation-impacting.

The ALLOCATION ledger holds overhead-redistribution journals (head-office costs pushed out to branches). For PWG it carries on the order of 60+ batches per month, all against BranchID = PWG, all Module = GL. None of these currently land in PWG_DATA’s staging tables — Azure Data Factory implicitly filters MYOB GL loads to LedgerID = ACTUAL only.

Effect on finance reports. Any P&L view in PWG_DATA / Hex that uses MYOB GL will under-state allocated overhead per branch relative to the MYOB-native P&L report. Reconciliations against MYOB at the consolidated PWG level still tie because allocations net to zero across branches; the gap shows up branch-by-branch.

Fix in flight. Phase B of the warehouse rebuild adds LedgerID to staging and CORE; Phase D of the MART rebuild filters explicitly via STAGING.MYOB_Ledger.IncludeInPL. Until both ship, trust the MYOB-native P&L over the warehouse for branch-level overhead.

Users and roles can’t be exported via API

Status: open. Process gap.

Users (SM201010) and Roles (SM201005) are not exposed by any published Web Service Endpoint on this tenant. The Security endpoint exposes only certificate entities; the Default endpoint exposes Employee but not User / Role.

Workaround. Manual UI export from each screen for periodic access review. Drop the files into the source repo’s data/ folder so they’re at least version-controlled.

Permanent fix. Either (a) the warehouse adds Users / Roles / UsersInRoles tables (raised as a DataMart backlog item), or (b) Axsys exposes a custom endpoint via AxsysAPI.

OAuth credentials are per-company, not per-user

Status: by-design. Operational gotcha.

MYOB Advanced’s OAuth model issues a separate application + client credentials for each company in the tenant. PWG and JV each have their own OAuth app. A single human user might have access to both, but external integrations need two distinct sets of credentials.

Effect. Any integration that touches both companies (the warehouse loads, for example) maintains two MCP servers, two refresh tokens, and double the credential-rotation work.

ReportingGroup endpoint returns HTTP 500

Status: open. Endpoint defect.

ReportingGroup is listed on the Default endpoint but returns HTTP 500 on every call. Not in active use, so not blocking, but worth flagging if anyone tries to build report-rollups via API.

Branch master entity does not exist on Default endpoint

Status: by-design. Schema quirk.

There is no standalone Branch entity on the Default/24.200.001 endpoint. Branch metadata is inlined as a column on transactional entities (JournalTransaction.BranchID, etc.). For a true master list you have to go to GLConsolidation/22.200.001, which exposes multi-company structure. We do not currently use that endpoint; branch lists are maintained by hand from the latest CoA extract.

JV branch list contains stray PWG-branch rows

Status: open. Data-quality.

Out of the JV branch enumeration, three rows look like they belong to PWG. Needs a finance-side check before the JV branch list can be published as authoritative. The six main JV branches we are confident about: POHM, PMAJOR, KWEALTH, KKP, MORE, MIFI.