FinSuite · Integrations
PTAS FinSuite Integrations
FinSuite runs in front of your system of record and posts into it. Here is how the connection is made.
What moves
What flows between FinSuite and your ledger
Masters and documents come in. Approved entries, attachments and status go out. FinSuite does the checking and the routing; the ERP stays the system of record.
Your ERP or accounting system
DocPro
Your configuration
FinSuite
Entries posted, not keyed
One entry per approved invoice, coded and matched, with the invoice image attached.
Status back in the queue
Document numbers, payment dates and holds come back, so FinSuite knows what was paid without anyone looking it up.
A trail on both sides
The ledger document number sits on the FinSuite record, and the invoice image sits on the ledger document.
The systems on this page are planning examples, and none of them is a packaged connector. Which ledger each entity runs, which interfaces your IT team will release and who approves what are confirmed during assessment.
All integrationsSystems of record
The systems FinSuite posts into
Each has a page of its own. Where we have described the route in detail, the card says which methods apply; where the route depends on your edition and version, it says so.
SAP, Oracle and QuickBooks pages describe the route we would propose for each: OData or BAPIs on SAP, the REST APIs or FBDI file loads on Oracle, the Accounting API on QuickBooks Online and files on Desktop. For Microsoft Dynamics, Tally, Zoho and NetSuite, the route depends on the edition, version and hosting you run, so the method is confirmed in discovery once we have seen yours.
Showing a system's name here is not a claim of partnership, certification or a marketplace listing. The SAP, Oracle and QuickBooks pages say plainly that we hold none for those systems, and a name on a card should not suggest otherwise for the rest.
Integration methods
Four ways to connect, named per system
Which one fits depends less on the ERP than on your IT team, your support contract and how many ledgers the group runs.
Native
What the system ships itself
Several ERPs have their own invoice capture or approval features, and some customers use them. We install nothing inside your ERP and claim no packaged connector or marketplace listing. Where the system's own feature fits your process, we say so.
API
Our default where one exists
FinSuite reads masters and posts entries through the interfaces the system releases, signed in as one integration user authorised for those calls and nothing broader.
File
Scheduled import files
A file in the format the ledger already imports, loaded on a schedule, with the import report read back for rejections. Slower than an API, and often the easier route to get approved.
Custom
Several entities or systems
Several ledgers, an ERP migration part way through, or a procurement system in front of the ERP. Orchestration sits on top: one queue, one approval policy, one mapping per entity.
Illustrative example: one group, four systems, four routes
Illustrative data. A group with several ledgers is one FinSuite rollout with a mapping per entity, rather than four separate projects.
Field mapping
Where each finance object lands
The mapping is agreed before build and kept per entity, in the terms your ERP team already uses. This is the starting point we bring to an assessment.
The entry, on both sides · Illustrative example
Field mapping is yours to define. Entries are validated against it before they reach the ERP, not rejected by it afterwards.
Status written back
What comes back from the ledger
Posting is half the job. FinSuite reads back what the ERP did with each entry, so nobody has to log in to find out.
Illustrative example: what the ERP tells FinSuite afterwards
Illustrative data. An invoice held in the ERP shows as held in FinSuite, so the answer to a supplier's query sits in one place.
One place approves. If your finance team already approves inside the ERP, FinSuite hands over a complete document and the approval stays there. Otherwise FinSuite holds the invoice until the right person approves, then posts. Running both would mean two approvals that can disagree, and we would not set it up that way.
A posting the ERP refuses is kept with the message it gave and sent to a person. A closed period or a blocked vendor is a decision for your team, and a retry loop would only hide it.
Security of the connection
What protects the link to your ledger
Four controls, each one visible to your ERP and security teams. None of them depends on trusting us.
An integration user your team creates
FinSuite signs in as a system user authorised for the calls it makes and nothing broader. Credentials are stored encrypted and rotated on your schedule, and the user can be disabled in your ERP at any time.
A route your security team approves
An on-premise ledger stays behind your firewall, and traffic arrives by the route your security team signs off. FinSuite itself can run on-premise or air-gapped where supported.
Every call logged with its evidence
Each read and posting is recorded with the document it came from, who approved it and the document number the ledger returned.
Test system first
Where your ERP has a test or quality system, the mapping is built and checked there, and moves to production through your change control after your finance team has seen the postings.
Approval bands, segregation of duties and the limits on what FinSuite may write are set out on FinSuite Security.
FAQ
Questions ERP and finance systems teams ask
Do you have a native connector for our ERP?
Not one we would claim. FinSuite connects through the interfaces your system releases: an API where there is one, an import file where there is not, and custom orchestration where several systems are involved. The SAP, Oracle and QuickBooks pages describe those routes in detail. For other systems the method is confirmed in discovery against the version you run.
We run SAP at group level and Tally in India. Is that two integrations?
It is one FinSuite rollout with two routes and one mapping per entity. Each ledger keeps its own tax codes, accounts and tolerances. The queue is shared, with the entity as a dimension, so one team can work both.
Will invoices appear in our ERP before they are approved?
Only if you want them to. Where your team approves inside the ERP, FinSuite hands over a complete document and leaves the approval there. Otherwise FinSuite holds the invoice until the right person approves it, then posts. One place approves, never both.
What happens when the ERP rejects a posting?
The rejection is kept with the message the ERP returned and goes to a person. A closed period, a blocked vendor or a missing cost centre needs a decision from your team, so FinSuite does not keep retrying it.
How long does an integration take?
It is built inside the FinSuite rollout, which typically takes 4 to 12 weeks. That is an indicative range that varies with document types, workflows, integrations and deployment. A file route is usually quicker to get approved; an API route is quicker in daily running.
Keep reading
Where to go next
All integrations
ERPs, accounting suites, the REST API and webhooks in one list.
Read more →FinSuite Security
Approval bands, segregation of duties and the ERP rights FinSuite is given.
Read more →DocPro Integrations
How documents reach DocPro and where its records can go without FinSuite.
Read more →From Document to Finance Action
DocPro and FinSuite on a single invoice, from capture to the posted entry.
Read more →Next step
Tell us which ledgers the entries have to land in
The finance workflow assessment asks which system each entity runs and how invoices reach it today. The answers shape the integration before anyone writes a mapping.