Automate bexio document intake and review

What bexio describes. bexio describes supplier invoice and expense processing, uploads through bexio Go and automatic reading of QR invoices in its feature overview. These vendor statements do not replace testing your documents and subscription. They do provide a reason to assess existing capabilities before buying another extraction service. bexio feature overview, checked on 26 September 2026.

Follow ten documents. Follow ten representative documents through your current process. Determine where time is actually spent: collecting attachments, reading fields, matching suppliers, resolving questions or obtaining approval. If extraction already works adequately, a second OCR service may contribute little. A consolidated intake channel or clear ownership rule may address the real delay.

Count completed transactions. Measure completed business transactions rather than uploaded PDFs. A stored file is not a fully reviewed supplier invoice. Recognised QR payment details also do not establish that the underlying goods or services were correctly invoiced. Keep these distinctions visible in the status information employees use.

The API documentation lists file operations under /3.0/files and supplier bills under /4.0/purchase/bills. Uploading a file and creating a bill are separate operations. The bill schema requires references, dates, currency and line-item data, among other values. bexio API documentation. Check the active version and permissions; this article describes an integration design, not an already tested connector.

A bexio document integration can have one of three scopes:

1. Intake and storage only: collect files from an approved channel, identify them consistently and transfer them to the intended inbox. Processing continues in bexio. This fits a business whose main problem is scattered attachments.
2. Checks before handoff: an external workflow identifies document types, missing information and possible duplicates. It adds provenance and ownership before a person takes responsibility for the invoice. This helps with mixed mailboxes and inconsistent supplier documents.
3. Structured record creation: create a supported invoice record after the mapping has been approved. This requires evidence for contact references, currencies, line items, attachment connections and failure handling. It involves more work because the integration is now carrying accounting decisions rather than merely moving files.

Company. The company should come from the intake channel or a verified reference. A company name found in a document is insufficient when related businesses have similar names. Record company identity before extraction and make subsequent changes traceable.

Supplier. For supplier matching, approved identifiers are stronger evidence than a similar name. A match remains a suggestion when several contacts could apply. Do not automatically create a new contact from every unfamiliar letterhead. That replaces typing with a growing master-data cleanup problem.

Mapping table. Use a mapping table to assign responsibility for invoice date, due date, currency, amount and accounting classification. Do not fill a missing due date with an invented standard term. Any permitted internal calculation needs explicit agreement and should remain distinguishable from a value read directly from the document.

Missing data. The mapping should also describe what happens when data is absent. For example, an unknown supplier can wait for a contact decision while a clearly identified invoice proceeds to ordinary review. Do not silently drop the difficult case or force it into a default supplier simply to keep the automation rate high.

The situation. This is a synthetic example. A supplier sends an invoice for CHF 1,080 with its delivery note. The following day, an employee forwards the same invoice again. A careless workflow could treat the three files as three separate invoices to process.

Matching. The proposed workflow first distinguishes the invoice from the delivery note. Both receive a connection to the same case, but only the invoice supplies the invoice number and payable amount. The second submission is compared with the existing case using company, verified supplier, invoice number, currency and amount. An identical file hash is useful additional evidence but will not identify a newly scanned copy on its own.

Review and acknowledgement. Accounting checks the proposed record against the source. After creation is acknowledged, the workflow stores the destination identifier. If the technical response is lost, the integration reconciles the destination state or asks for review. It does not create another bill as a precaution.

The workflow responds to five typical bexio intake situations as follows:

This example also shows why a file-level success counter is misleading. Two legitimate attachments and one repeated submission should produce one invoice case, with all relevant evidence retained. The reconciliation report must explain that difference.

Reconcile intake with destination records

Maintain a compact list of source case identifiers, destination references and states. Compare expected transactions with acknowledged bills, deliberately excluded material and open checks. Explain why file count and invoice count differ.

A synthetic day contains 40 invoices, four delivery notes and three repeated submissions. It should produce 40 invoice cases, not 47. If two supplier assignments remain unresolved, the first reconciliation shows 38 confirmed and two open. Continue only those two after clarification.

During an outage, a manually entered bexio record must become visible to the external queue before automation resumes. Define a controlled reconciliation procedure with the responsible person. Blindly replaying the entire day risks repeated capture.

Access rights and outsourced processing

Grant only the rights required and keep document import separate from payment actions. Document which additional services receive the source, extracted text or diagnostic logs. Error messages can contain invoice information too. The responsible business retains responsibility when processing is outsourced; the Swiss data-protection authority explains the relevant outsourcing requirements. FDPIC guidance on outsourcing.

Monitoring unresolved cases

Maintain an operational queue showing unresolved cases, age, reason and owner. A green workflow run does not establish completion. Reconcile intake counts against acknowledged destination cases and intentionally excluded files. Investigate unexplained differences before treating a reporting period as complete.

Acceptance testing after changes

Repeat a fixed test set after mapping changes or an API upgrade. Include a QR invoice, ordinary PDF, multipage document, credit note, duplicate, unknown contact and deliberate validation failure. Use approved test data and inspect the outcome from the fiduciary or accountant's perspective as well as the integration operator's.

Three connected artefacts. A demonstration should show three connected artefacts: the unchanged original, reviewed internal data and the visible result in bexio. Ask the operator to move between them. If files must be located manually or values copied again, the complete path has not yet been demonstrated.

An incomplete record. Include a deliberately incomplete record. The workflow should explain the missing information and its owner, with a source link. After correction, confirm that the existing case continues with its history preserved. A disconnected technical error message is not an adequate review process.

Realistic variety. Use different suppliers, multipage documents and foreign currencies where they belong to your real workload. This does not prove every future variant, but it demonstrates the basic controls and correction path for the agreed scope.

In a synthetic case, a Swiss company receives an EUR 800 invoice while accounting in another base currency. Extraction supplies the original amount and currency. It has not yet established the appropriate accounting conversion.

The responsible specialist defines the conversion rule and its source. Keep original amount, original currency, approved conversion or destination valuation and provenance separate. Derive the actual required API fields from the current documentation for the selected operation. This example is not a complete request payload.

Test an approved conversion, a missing value and an implausible value. The first must produce the intended destination amounts; the others remain unresolved before unapproved transfer. A model should not invent a missing exchange rate from general knowledge.

A new supplier and a new bank account for an existing supplier are different events. For a new contact, check whether a record already exists under another spelling. Changed payment information needs the business's independent confirmation process.

Show current master data beside the source information. Record the reason and owner of an approved change. Extraction may capture a suggestion, but it should not merge master-data amendment and approval of the associated invoice into one unchecked action.

Define how a rejected suggestion is corrected. A single contact correction should not automatically create a permanent rule for every similarly named business. Approve lasting mapping changes separately so one mistake does not propagate across later invoices.

Assign responsibility for mapping, permissions and connections. Accounting owns business rules; the operator implements them within the approved scope. Repeat critical acceptance cases after changes and retain the previous approved configuration.

Plan for replacing the additional service. The business should be able to recover originals, processing states and destination associations. Extracted text alone is insufficient. Request an export containing source and target references so unresolved cases can be transferred without creating unchecked duplicate records.

Compare the current effort with the complete future process, including questions, corrections and operation. At low volumes, consistent use of an existing inbox can be less expensive than maintaining a custom integration. Multiple channels or unusual approval requirements can justify targeted preparation work.

A useful implementation brief identifies the intake channel, intended operation, subscription scope, responsible accounting person and acceptance criteria. Ask to see a complete transfer with an accessible source and a failure case. That establishes whether the workflow reduces real administrative work rather than simply reading text quickly.

These guides and service pages cover the decisions next to a bexio document workflow:

• AI document processing: capture, review and transfer
• Automate Swiss fiduciary document and client workflows
• Plan an Abacus document integration before adding AI
• Connect n8n to ERP systems with supported interfaces
• Detect duplicate invoices with business keys and review

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.