Connecting business software to accounting, banks and government mailboxes
Your accountant downloads statements by hand, payment approvals sit in email threads, and one employee monitors official correspondence. Connecting these workflows can help, but they do not share the same permissions or meaning of success. Start with the actions you need and the evidence each action must produce.
01Specify actions rather than a list of products
“Connect the bank” might mean reading transactions, matching receipts, preparing a payment batch or actually initiating a transfer. Those actions have different consequences. For official correspondence, listing messages, downloading attachments, assigning work and submitting a response are equally distinct. A single integration checkbox in a proposal does not tell you which of these will work.
List the situations that currently involve retyping, waiting or uncertainty. For each one, identify the source, destination, required frequency and owner of exceptions. A supported file import may be enough for modest volumes. Assess custom development where repeated work, complex permissions or missing capabilities create a concrete problem, rather than assuming every connection requires a new platform.
| Area | Result to verify | Keep these distinct |
|---|---|---|
| Accounting | A record accepted in the correct ledger or module | File transfer and accounting completion |
| Banking | A known transaction or payment instruction state | A payment proposal and an executed payment |
| Official correspondence | A stored message with traceable status | Download, handling and legal delivery effects |
For the choice between file imports, ready-made connectors and custom work, see our guide to API integration.
02Accounting needs a mapping and a record-level response
Check the accounting product's edition, licence, supported modules and interface conditions. One regional example is POHODA's XML import documentation, which defines schemas and record-level processing details. Successful file transfer therefore should not be treated as confirmation that every record was accepted.
The vendor also publishes its supported import areas, including banking and invoicing. This Czech product example illustrates the questions to ask; it does not establish capabilities for every accounting package or regional edition. Require evidence for your specific reading, creation and correction operations.
Work with finance to map identifiers, currencies, number sequences, cost centres and statuses. Define which system owns each value and who may change it. A closed period should not be rewritten merely because an old transfer runs again. Test a partly rejected batch: retain the accepted results and give rejected items a clear reason and an accountable owner.
For a concrete document flow, read how to move online orders into accounting without retyping.
03Reading an account is different from moving money
Distinguish a bank's own API, a contractual corporate channel and an open banking service. For example, the Czech Fio API documentation describes payment batches uploaded for signing in online banking, alongside a separate open banking interface for licensed providers. This is a specific implementation, not a universal banking pattern.
The European PSD2 framework distinguishes account information from payment initiation, with consent and authentication rules and exceptions. It is not a global entitlement to unrestricted access through a universal API key. Confirm the applicable jurisdiction, provider permissions and approval process with the bank for the intended channel.
If you only need to match incoming receipts, start with appropriately limited access rather than permission to send money. For payments, separate preparation, recipient checking and approval. Design for rejection, revoked access and changes in authorised personnel. Give reconnection and credential renewal an owner and a deputy before launch. An integration that depends on one unavailable employee has not removed the original operational weakness.
04Treat government mailboxes as country-specific systems
There is no universal government inbox API. In Czechia, ISDS data boxes have official web services and a test environment for external applications, described in the developer guidance. Use the relevant testing process rather than experimenting with live official correspondence.
Slovakia uses electronic mailboxes through its ÚPVS framework and slovensko.sk. Article 30 of the portal conditions describes a separate integration process, integration agreement and technical account. A Czech connector cannot simply be relabelled as a Slovak one. Other countries require their own channel and eligibility assessment.
Within your workflow, distinguish downloading a message, assigning it to a colleague and completing the required action. Preserve identifiers, necessary attachments and available evidence of communication status. Do not infer legal delivery effects from an internal “Read” button. Have the consequences of specific operations and applicable deadlines checked for the relevant jurisdiction and message type.
Design retention separately: what is kept, who can access it, how long it is needed and how recovery will be verified. Avoid assuming that an official portal will retain every item indefinitely. Automated downloading without completeness checks, access controls and recovery testing is not a finished archive. A company operating in several countries needs a shared oversight process with explicitly different local connectors.
05Resolve the outcome before retrying an uncertain action
Give each transfer an identifier, source, destination and last verified outcome. Idempotency means that repeating the same request does not produce an additional unintended effect. It is something to design and test for a particular operation, not an automatic benefit of using an API.
Consider an illustrative case: the system sends an accounting record, but the connection fails before the response arrives. It first attempts to find the outcome through the shared identifier, then decides whether to retry. For payments and official submissions, an unknown outcome must not be casually treated as failure. Where the state cannot be established automatically, create a clear task for an authorised person.
In an API integration brief, ask for exception handling as well as data movement. Finance staff should understand which record is waiting and which detail requires correction. Routine recovery should not depend on a developer being the only person who can interpret a technical log.
06Assign ownership of permissions and exceptions
Keep an inventory of credentials with their owner, scope and revocation procedure. Secrets and certificates do not belong in a project spreadsheet or source code. Separate testing from production and match access to the role: reading balances, correcting records, approving payments and submitting official documents are different responsibilities.
An operational record should establish who initiated an action and which result was verified. It need not expose full statements, every attachment or access tokens to a broad support team. Agree who fixes a content error, who restores connectivity and who decides what to do when the outcome remains uncertain. Otherwise, automation simply moves work into a less understandable queue.
Include supplier responsibilities in that agreement. A business owner should know whom to contact when a bank changes an authentication flow or an accounting upgrade changes accepted fields. Define which changes are included in support and what evidence the team needs to investigate a failure. This is part of operating the connection, not optional documentation added after launch. Restoring a connector is also different from deciding whether an accounting record is correct. Give the accounting content a named owner within finance or your external accounting service, with a clear handover between both roles.
07Launch in stages with observable acceptance criteria
Choose a narrow first stage with a result you can verify. You might begin with reading and reconciliation, then add controlled writes. Each stage needs an owner and a recovery plan. Ongoing maintenance and support should cover interface changes, access renewal and backup checks.
- Run a normal case and a record the destination rejects.
- Repeat the same request and inspect duplicate handling.
- Interrupt the connection after sending but before receiving a response.
- Revoke test access and check the notification reaches its owner.
- Restore a saved document and its associated operational evidence.
- Ask a deputy to resolve an exception using the written procedure.
Monitor the last successful synchronisation, the age of the oldest unresolved error and the cases waiting for a person. A running server is not evidence that useful work is progressing. The connection can appear available while no new record has reached its destination for days.
08Frequently asked questions
Do all three areas need to launch together?
No. Start with a task that has clear value and a verifiable outcome. Add more consequential approvals and submissions once the first stage is operating reliably.
Is a vendor's claim of API support sufficient?
No. Request supported operations, access conditions, error behaviour and a demonstration of your specific workflow in the product version you use.
Can software send payments without human involvement?
That depends on the banking channel, permissions and approval arrangement. An ability to upload a payment file does not establish unattended payment execution.
Does a mailbox connection include archiving?
Not automatically. Retention, access control, completeness checking and recovery need their own design and acceptance tests, appropriate to the relevant country and document type.
09Prepare your integration brief
Send us your systems, banks and official communication channels, plus three manual tasks. We can define a first stage with a verifiable result, appropriate permissions and a workable exception process.