Which integration route should we use for e-invoicing?
Use an API when a system issues invoices continuously and needs a status back within the same workflow. Use file transfer through a connector when a system produces batches and changing it is costly. Use spreadsheet import or manual entry for low volumes, occasional documents or as a bridge while a deeper integration is built. Many businesses combine routes, one per issuing system.
Start from your systems, not from the technology
Before comparing routes, list every system that issues invoices, credit notes or debit notes: the ERP, a billing platform, a point-of-sale back office, a project system, a spreadsheet kept by one team. For each, note monthly volume, whether documents are created one at a time or in batches, how quickly you need a validation result, and who can make changes to it. Those four facts usually decide the route.
Route 1: REST API
An API connects your system directly to the e-invoicing platform. Your system sends each document as it is created and receives the validation result and lifecycle status in return, so errors can be shown to the person who raised the invoice while they still have the context.
Invoice And Tax offers a versioned REST API under /api/v1/, with bearer API keys that are shown once and scoped to an organisation or branch. It comes with an OpenAPI 3.1 specification, a Postman collection and a quick-start guide. See the API page for details.
Best for: continuous volumes, modern systems with developer access, and processes where an immediate status matters.
Route 2: File transfer through a connector
Many established systems are better at producing files than calling APIs. A connector picks up those outputs, maps them to the document model and returns results the same way. Invoice And Tax provides a connector framework with several transports: REST/JSON, SOAP/XML, OData, GraphQL, SFTP, direct database, a local agent and manual upload. The right transport depends on what your system can already produce, which keeps changes to that system small.
Best for: batch-oriented systems, older platforms where changes are slow or costly, and scheduled runs.
Route 3: Spreadsheet import and manual entry
Not every invoice comes from a system. Some teams issue a handful of documents a month; others need a bridge while a deeper integration is built. Excel and CSV import, with mapping and checks, and manual entry both feed the same shared document composer used by every other route, so the same validation applies. See Excel and CSV import.
Best for: low volumes, occasional documents, pilots and transitional periods.
Factors that decide the choice
- Volume and rhythm: continuous flow favours an API; daily or weekly batches suit file transfer.
- Feedback loop: if the person raising an invoice must see a rejection immediately, choose an API.
- Change cost: where a system is hard to modify, a connector that reads its existing outputs is usually cheaper.
- Control: every route should end in the same validation and audit trail, so control should not depend on the route.
- Hosting: Invoice And Tax supports cloud, private cloud, on-premises, desktop and hybrid deployment modes, which affects how connectors reach your systems.
Combining routes
Most organisations end up with more than one route: an API for the main ERP, a connector for a legacy billing system, and spreadsheet import for a small subsidiary. Because all three feed one document composer and one set of versioned validation rules and Schematron conformance checks, the results are consistent whichever route a document takes. For accounting software, a Zoho Books connector brings supported invoice data into Invoice And Tax through a tested, operational integration workflow.
The integrations overview brings the options together.
| REST API | File transfer (connector) | Spreadsheet import / manual entry | |
|---|---|---|---|
| Typical volume | Continuous, medium to high | Batches, medium to high | Low or occasional |
| Feedback speed | Immediate, in the same workflow | After each batch run | During import or entry |
| Change to your system | Development work | Usually small; reads existing outputs | None |
| Validation | Same rules and checks | Same rules and checks | Same rules and checks |
Questions about integration
Can we start with spreadsheets and move to an API later?
Yes. Because every route feeds the same document composer, documents behave the same way after you switch, and your validation history stays in one place.
Do we need developers to use the API?
Some development work is needed in the system that calls the API. The OpenAPI 3.1 specification, Postman collection and quick-start guide are designed to shorten it.
Can the platform run inside our own environment?
Deployment modes include cloud, private cloud, on-premises, desktop and hybrid. The right mode is agreed during onboarding.