Skip to main content

Administrator changes

The administrator changes node on a bank report (administratorChanges) captures every change to the organization's administrators that the customer recorded in this report — new admins, departing admins, role updates, and per‑administrator changes to attorneys and bank‑account access.

Shape​

administratorChanges itself is thin: an id and an administratorChange list. The interesting structure lives on the list items, which implement the AdministratorChange interface.

AdministratorChange has two concrete implementations:

  • BoardMemberChange — wraps a board member, exposes boardMember (with the underlying user) and boardMemberRoleChanges (one entry per added/kept role).
  • ExternalAdministratorChange — wraps an external administrator (typically appointed via power of attorney rather than elected). Exposes externalAdministrator and externalAdministratorRoleChanges.

Query both with inline fragments — the shared interface fields project at the top level, and the concrete ones go inside ... on BoardMemberChange { … } / ... on ExternalAdministratorChange { … }.

Interface fields​

Every AdministratorChange carries:

  • isNew — the administrator was added in this report.
  • isLeaving — the administrator is being removed in this report.
  • isAuthorizedSignatory plus isAuthorizedSignatoryChanged — current state and whether it changed.
  • hasRolesChanged — at least one role added or removed.
  • hasChanged — true when any of the above is true or any attorneyChange.hasChanged is true.
  • informationFile — a .txt with bookkeeping information about the administrator.
  • attorneysFile / signedAttorneysFile — the attorneys overview PDF and its signed counterpart.
  • attorneyChanges — list of per‑attorney changes (rights, bank card flag, the affected bank account).

Bank reports for companies​

A bank report for a company (organization.discriminator is "Company") lists every person in the company when it submitted the report, through the same two types:

  • An internal administrator — director, board member, owner, employee — is a BoardMemberChange. boardMember resolves the person with the usual BoardMember fields. Its boardMemberRoles, and the change's boardMemberRoleChanges, are empty, because a company's roles are not association roles. These fields carry them instead:
    • companyInternalAdministratorRoles — any of MANAGING_DIRECTOR, DIRECTOR, CHAIRMAN_OF_THE_BOARD, BOARD_MEMBER, OWNER, EMPLOYEE and OTHER.
    • ownershipPercent or ownershipInterval, and votingPercent or votingInterval — each share is either an exact percent or a CVR band, never both. A band is given as its lower bound in percent: 0 (under 5 %), 5, 10, 15, 20, 25, 33.33, 50, 66.67, 90 or 100.
    • isBeneficialOwner — the person is a beneficial owner (reel ejer).
  • An external administrator — revisor, bogholder, advokat — is an ExternalAdministratorChange. externalAdministrator resolves the person, externalAdministratorRoleChanges is empty, and companyExternalAdministratorRoles holds any of ACCOUNTANT, BOOKKEEPER, LAWYER and OTHER.

The company fields are null on a bank report for an association. A company's contact person is not listed: being your bank's contact for the company is not a position in it.

Attorneys and bank accounts​

attorneyChanges[].bankAccount exposes accountName, registrationNumber, and accountNumber. rights and bankCard describe what level of access the attorney now has and whether they are entitled to a bank card. Attorney changes are scoped to administrators — there is no top‑level "attorneys" or "bank accounts" node on a bank report; everything attorney‑related is reached via this path.

The attorneyChanges lists are populated on reports created with the legacy attorney representation (hasDynamicAttorneyModule: false on the bank report). Reports created with the dynamic representation carry their attorney data in dynamicAttorneyChanges instead, and the legacy lists are empty, unless unioo support has enabled legacy attorney changes for your bank.

With legacy attorney changes enabled, an association's attorneyChanges on a dynamic report are built from the administrator's procura and card changes, one entry per bank account:

  • rights is the legacy right unioo support has set on the procura setting the administrator holds on the account. No procura held, or only a removed one, gives NONE. A procura over every account gives its legacy right on each of the organization's bank accounts.
  • bankCard is true when the administrator holds a card on the account that is not removed.
  • hasChanged is true when any of the procura or card changes on the account is not UNCHANGED, and the administrator's own hasChanged counts it as on legacy reports.
  • id is stable across requests, but there is no attorney change behind it to look up.

unioo support sets a legacy right on every procura setting your bank has for associations, archived ones included, before enabling legacy attorney changes. Should a report still hold a procura whose setting has none, its right is not guessed. Its bank account is left out of the list, and the response carries an error with extensions.code of LEGACY_ATTORNEY_RIGHTS_UNMAPPED naming the setting. For a procura over every account, that is every bank account. Contact unioo support to have its legacy right set.

On reports created with the dynamic representation, attorneysFile is not the generated overview PDF but the administrator's dynamic attorney documents — their card change documents followed by their aggregated procura document — merged into one PDF, so a consumer still reading this field keeps getting one document per administrator. The merge is a concatenation, so it has no cover page or summary table, its page order follows the underlying documents, and it is built when you request the bytes rather than stored. signedAttorneysFile is always null on those reports: merging re-writes the pages into a new document, which would not carry the sources' signatures.

The merge contains the documents that exist. A change whose document has not been generated — file is null, which is ordinary on reports that required no signature — is simply not in it, and the merged file gives you no way to tell. It is a convenience document, not the record of what the administrator was granted: read dynamicAttorneyChanges for that, where every change is listed whether its document is there or not, signed versions included.

Telling an empty file apart from a failed one​

attorneysFile is null both when there is nothing to serve and when a document exists but could not be read — a storage failure, or a source that is not a readable PDF. The two are distinguished by the errors array, not by data:

  • attorneysFile: null and no error — there are no documents for this administrator (or your bank does not have the DynamicAttorneys module).
  • attorneysFile: null and an error with extensions.code of MERGED_FILE_UNAVAILABLE — documents exist and could not be served. Retry; do not record this as an administrator without attorneys. A partial document is never served, so the file is either complete or absent.

If you store what you read from this field, check errors for that code before treating a null as an absence. One unreadable document affects only that administrator's attorneysFile — the rest of the response, including every other administrator, is unaffected.

Required gate​

The whole node is meaningful only when isAdministratorsRequired is true on the parent bank report. When it's false, the package didn't request administrator changes and administratorChanges will be empty.

Where to query​

See Querying administrator changes. To reject a package because of an administrator‑related problem, use rejectAuthorizedSignatories: true or — for the per‑member attorney documents — rejectBoardMemberAttorneys: true on rejectBankPackageById.