NGO ERP Integrations: Banks, Payroll, BI, SSO and APIs

Which system owns each object?

For broader context, see ERP integration architecture. The NGO-specific design must preserve award, fund, programme and entity identifiers across bank, payroll, donor and reporting endpoints.

Create an ownership map for donors, awards, suppliers, employees, payments and programme indicators. Specify where each object is created and which application may update each relevant field. Two systems can hold copies without having equal authority to change them.

Set ownership boundaries across ERP, accounting, CRM and grant management applications. For example, a donor CRM may own relationship details, while finance owns a posted receipt. A payroll provider may calculate payroll while ERP receives an approved accounting summary. Keep these events distinct.

Include stable identifiers and lifecycle states in the data contract. “Employee active” may mean different things in payroll and access management. Agree the mapping and the action taken when a source record is missing, closed or inconsistent.

Read access does not authorise a write

Classify each connection by business authority. Reading approved totals for business intelligence, or BI, is different from creating a supplier or instructing a bank payment. Separate credentials and permissions where the risks differ.

For programme cost and result reporting, preserve aggregation rules as well as identifiers. An interface that copies every row correctly can still produce incorrect totals if downstream joins multiply expenses or participants.

Identity and payment services have distinct responsibilities

Single sign-on, or SSO, connects identity authentication, but application permissions still need governance. Specify how new users receive roles, how assignment changes are applied and what happens when access is withdrawn.

The security requirements should cover service accounts, exported data and privileged actions. An integration user should receive only the authority needed for its purpose. A reporting connector does not need payment-release privileges simply because both use the same application programming interface (API).

For payment workflows, distinguish preparation, approval, submission, acceptance and settlement. A successful transport response may mean the provider received a request, not that funds settled. Retain the external reference and reconcile later status changes to the original approved instruction.

A small interface contract

This event model is an integration design example, not a Causeway API specification.

The donor CRM owns the supporter and gift intent; the processor owns payment outcome; finance owns the approved posting; BI receives approved reporting records; the identity provider authenticates users while ERP authorises their actions. An award system owns accepted grant conditions until that responsibility is explicitly transferred.

The flow is CRM gift → processor payment → verified event intake → reviewed ledger posting → bank reconciliation. On a timeout after EVT-001 was accepted, query the original reference, then replay only under the provider contract. The expected result remains one USD 100 gift, one USD 3 fee and one USD 97 net receipt. A duplicate event is recorded as another delivery attempt, not another gift.

A lost response does not prove a failed transaction

Suppose a payment request is sent and the connection times out before the response arrives. The receiving system may already have accepted it. Blindly sending a new business request can create a duplicate. The recovery process should first establish the status of the original request using a stable reference and the provider's supported behaviour.

Where supported, an idempotency key identifies repeated attempts at the same operation. It does not replace the need to understand the receiving system's guarantees, expiry rules and business semantics. Record attempts separately from the business transaction so an operator can see what happened.

Reconcile counts, values and statuses over a defined population. A source total matching a destination total does not prove every individual record is correct if duplicates and omissions offset one another. Include identifier-level exceptions and an owner for resolving them.

Who sees the failure and recovers the record?

Define what creates an alert, who receives it and what action they may take. Distinguish temporary failures from invalid data and authority problems. Repeating an invalid request every minute does not resolve its cause and can obscure more important incidents.

Maintain a controlled queue for failed or unresolved records. Operators should see the source reference, error category, attempts, current status and next action without exposing unnecessary personal data or secrets. Recovery actions need an audit trail.

Include these dependencies in the implementation plan. External providers may require credentials, test environments, approval or contractual arrangements. An integration cannot be considered ready merely because the ERP team completed its side of the code.

Test interface dependencies

Use test records to test normal processing, timeout, duplicate attempt, invalid identifier, revoked credential and out-of-order update. Calculate expected records and totals in advance. Confirm that monitoring detects the failure and that the authorised operator can recover without creating a second transaction.

Test reconciliation after a correction. If the source changes a posted record, decide whether the destination receives an amendment, reversal or another governed event. Do not allow an interface to silently rewrite financial history without the approved treatment.

Document the supported version, rate or volume constraints where relevant, and responsibility for changes. A connector requires maintenance when either system evolves. Include that work in the operating scope and cost comparison.

An implementation reference is useful when it identifies the interfaces and responsibilities involved. Compare the connected NGO operating-model case study with your own integration boundary and request evidence for the failure scenarios that matter to your team.

Reconcile donation events with bank settlement

A fundraising platform may record the donor's gift while a payment provider records authorisation, collection, refunds and settlement. The ERP needs stable references linking these events. Model the gross gift, fees, net payout and any later adjustment separately so a bank deposit containing many gifts can be explained.

Stripe's webhook documentation warns that events can be duplicated and are not guaranteed to arrive in order. Verify signatures, record processed event identities and retrieve the current provider state where necessary. A late event should not reverse a newer accepted state simply because it arrived last.

Test a repeated notification, a missing notification, a refund after settlement and a payout containing transactions from two reporting periods. Compare provider totals, integration records and ledger entries. Donation payment reconciliation should have a named finance owner rather than depending entirely on the integration developer.

Separate instructions from statements

A bank-statement feed reads transactions already recorded by a bank. A payment instruction requests a new movement of money. Keep their credentials, approvals and monitoring requirements distinct. For cross-border disbursements, also retain recipient currency, provider charges, exchange details and returned-payment reasons.

Where several providers are involved, an ERP integration consulting assessment can define the interface responsibilities and test scope. Confirm access and testing arrangements with each external provider before treating the integration as deliverable.

Assign record ownership, reconciliation and recovery routes with the NGO Integration Map Generator.

Frequently asked questions