An accounting connector asks for new permissions: what should you approve?

A connector that previously read transactions may ask for broader access when a feature changes or its authorization is renewed. Before accepting, ask what new business task requires the permission. Translate the consent screen into capabilities the finance team understands: read records, create invoices, alter suppliers, access another company or perform another supported action. A generic request to reconnect does not explain why the application needs a larger authority boundary.

RFC 9700, the OAuth security best-current-practice document, recommends restricting access-token privileges to the minimum needed for the application or use case. It also addresses restrictions on resources and actions. Apply that principle through the actual provider's available permission model. Some platforms offer coarse scopes, so a consent label may cover more than one activity. Confirm those limits rather than assuming a neatly separated read-only option always exists.

Start the connection through the provider's established application or a verified vendor route. Confirm the application name, publisher and requested destination. Check which legal entity or account is selected before granting access. A group finance user may have access to several companies, and an apparently successful connection can still point the connector at the wrong one. Record the stable company reference as well as the display name.

Ask whether the request is expected. Compare it with the vendor's release notice, support ticket or agreed implementation plan. A colleague's forwarded link is not enough to establish that an unfamiliar application should receive access to the ledger. If the request is unexpected, verify it with the known vendor contact using an independent route. Keep credentials and authorization codes out of email threads, screenshots and shared troubleshooting documents.

Identify the person authorized to grant consent and the internal owner accountable for the connection afterward. The operator who can click approve may not be the person who should decide whether a new write capability is acceptable. Have the business and security owners review the material change before consent. Keep that decision specific to the application, company, purpose and scope so a later audit does not have to infer intent from a successful connection event.

Request a capability explanation that maps each new permission to the records and operations the connector will use. Distinguish technical permission from configured behavior. An application may currently use a broad scope only to read one record type, but the granted capability can still be broader. Ask what prevents unintended operations, how configuration changes are approved and what activity evidence is available. Do not accept a description of today's user interface as proof of the underlying access limit.

Review sensitive fields and actions separately. Supplier banking information, employee records, customer details and posted journals may require different internal approvals. If the application needs a coarse permission for a narrow task, identify the compensating controls and the person accepting the remaining risk. The answer may be to use a different supported method or defer the feature. It should not be to grant full administrator access automatically because a limited connection takes more work to configure.

Consider an illustrative reporting connector that requests the ability to create invoices for a new automation feature. The finance team may want its existing reporting service while declining the new posting workflow. Ask whether the provider supports that separation. If it does not, evaluate the combined service explicitly. A feature announcement should not silently convert an information-access purchase into a system capable of creating obligations or customer communications.

Use the provider's supported nonproduction environment where available. Demonstrate the required operation and verify that disallowed actions are denied by the applicable controls. Test the selected company boundary with synthetic data. Review the actual result in the source and destination rather than accepting a green connection status. Record any production-only behavior that the test cannot establish and assign a bounded verification step for it.

Check the reporting and exception behavior when consent is denied, expires or is revoked. The connector should make the resulting gap visible rather than reporting a fresh successful sync with no data. Identify which jobs stop and what records need recovery when access returns. The business owner should understand the operational effect before the old authorization is replaced, especially near payroll, billing or close deadlines.

Do not test write permissions by creating uncontrolled live transactions. A safe demonstration should use approved test records and avoid real payments or customer messages. Where a limited production verification is necessary, define the record, expected result, authorized operator and cleanup or reversal process beforehand. A permissions review succeeds when it establishes both the required business capability and the limits around it, without introducing unrelated financial activity.

Retain the approved purpose, scopes, company references, consent date, internal owner and vendor support route. Store secrets only in the approved credential system. Document how to disconnect the application at both the source platform and the connector, and which records or retained data remain afterward. Revoking future access does not necessarily delete copies the vendor already holds, so address retention and deletion through the applicable service arrangements.

Review existing integrations for overlapping work before activating a new write feature. Two authorized connectors can still create duplicate invoices if both own the same source population. Define the processing boundary and reconcile the first complete run. Keep the ability to pause the affected automation with an authorized owner. Permission is a prerequisite for an operation; it is not proof that the operation's accounting design is correct.

Revisit the grant when the service changes, the provider relationship ends or a new permission request appears. Compare the requested access with the original decision instead of approving from memory. The useful record lets the company explain why the connector has each material capability, who accepted it and how the connection can be stopped without losing track of unfinished finance work.