Mesh App to Lexoffice export: complete 2026 workflow

Instead of retyping invoice details into Lexoffice, set up a Mesh App Lexoffice export around a verified transfer route, a fixed field map and a reconciliation check. Confirm which records the destination accepts before moving live invoices; a contact import is not an invoice transfer.

Why this matters

Mesh App is best suited to small businesses that want CRM, project management and invoicing in a modular platform. Connecting those operational records to accounting needs a narrower decision: which system creates the invoice, and which system records its accounting treatment?

Start with Mesh App as the operational platform, then agree the accounting handover with the person responsible for Lexoffice. An invoice document, a customer record and an accounting entry are different objects. Moving one does not prove that the others exist or match.

For your 2026 setup, define success as an accepted record that reconciles to its source—not merely a downloaded file or a successful upload. The guide to connecting CRM and accounting software provides the broader context; the controls below keep this particular handover testable.

Before you start

• Access and ownership: Arrange access to the relevant invoicing records and the destination account. Name the person authorised to approve the accounting treatment and the person responsible for resolving rejected transfers.
• Transfer materials: Obtain the destination's current instructions for the exact record type you intend to transfer, plus a representative source record. Confirm the supported route in both accounts before preparing a batch.
• The gotcha: Do not assume that importing contacts, attaching invoice documents or transferring accounting entries produces the same result. Confirm the resulting object and whether the process creates an invoice, an attachment or a bookkeeping record before continuing.

Keep a written setup record dated 2026. Record the approved route, record type, mapping decisions and test outcome so another person can repeat the process without interpreting your spreadsheet.

Choose the transfer route

Use the simplest supported route that transfers the required accounting object. Do not select automation merely because it removes an upload step; an automated transfer with the wrong record type still needs correction.

The following are route-selection criteria, not claims that either account includes a particular connector or export format. Check support for the intended object before choosing.

If neither route supports the required object, stop the transfer setup. Agree an accountant-approved handover rather than trying to make an unrelated import function accept invoice data.

Transfer scope

Define the records and their owner

1. Choose the authoritative invoice record. Decide where invoice numbers, issue dates, corrections and original documents are maintained. Do not let two systems independently issue the same business invoice.
2. Define the batch boundary. Select a clear date range or another reproducible selection rule. State which date controls inclusion: invoice date, creation date or another agreed business date.
3. Separate record types. Identify invoices, credit notes, customer records and payments separately. Include each only when the chosen route supports its intended destination object.
4. Create a transfer register. Record the source identifier, batch reference, destination identifier when returned, transfer outcome and reconciliation result. Keep rejected records distinguishable from successful ones.

Expected result: You can explain exactly which records belong in the batch, who owns corrections and what each transferred record should become.

For a 2026 cutover, record the last completed batch before enabling the next process. A new procedure should begin from a known boundary, not from an assumption about what a previous export contained.

Keep drafts outside the accounting handover

Use an explicit readiness rule. A draft that still needs customer details or tax review should not enter the same queue as an approved invoice.

This is a process decision rather than a presumed software setting. Document how your team establishes readiness, who approves exceptions and where rejected records return for correction.

Field mapping

Match business meaning before column names

1. Obtain the current destination specification. Use the documented requirements for the chosen operation. Record required fields, accepted formats and any account-specific configuration that affects the result.
2. Map invoice identity and customer identity separately. Preserve the source invoice reference and the customer reference. Do not use a customer name alone as the matching rule: different records can share a name.
3. Map dates, currency and tax meaning. Establish how the route represents invoice dates, service dates where relevant, amounts, currency and tax treatment. Ask the accounting owner to approve tax-code relationships.
4. Decide how documents travel. Confirm whether the invoice document is included, attached separately or retained outside the transfer. Make its relationship to the accounting record traceable.
5. Record every transformation. Document any date conversion, decimal conversion or value mapping. Preserve the original source data rather than replacing it with the transformed version.

Expected result: Every required destination field has an identified source or an explicitly approved handling rule. No required value depends on guessing during the import.

Use this mapping worksheet as a business checklist. These are not promised interface labels or an import template.

Do not treat a matching column heading as proof of matching meaning. An amount field still needs a clear definition: net or gross, line or document, original currency or converted value.

Trial transfer

Run a small, controlled acceptance test

1. Prepare 3 test invoices and 1 credit note in an authorised test environment or another approved test procedure. Choose records that exercise the actual tax and document cases your business uses; do not invent unnecessary accounting scenarios.
2. Capture the source position. Record document counts, invoice references and expected amounts before transferring anything. Retain the source documents and the exact transfer payload or file.
3. Execute the approved route. Follow the current account documentation for the supported operation. Record the result for every submitted record, including any returned identifier or rejection message.
4. Inspect the destination records. Check customer identity, dates, currency, tax treatment and document linkage. Verify that the credit note has the intended accounting effect and reference.
5. Test duplicate handling safely. In the approved test procedure, submit the same source reference again and inspect the outcome. Do not repeat a live posting simply to discover whether duplicate protection exists.

Expected result: You can trace each source record to the intended destination object, explain every rejection and demonstrate what a repeated submission does.

The test sequence is Transfer scope, Field mapping, Trial transfer, Reconciliation. Keep those gates in order; a successful submission does not replace the final accounting check.

Reconciliation

Approve the batch before expanding it

1. Compare record counts. Account for accepted, rejected and deliberately excluded records. Investigate every difference instead of silently reducing the expected batch.
2. Compare 2 control totals: net and gross. Also inspect the tax breakdown, currency and sign of each correction. Compare like-for-like values rather than combining different currencies or record types into an unexplained total.
3. Resolve partial success. Mark successful records as completed in the transfer register. Correct rejected records and prepare a retry containing only the records that still require transfer.
4. Approve the operating procedure. Record the reviewer, completion date and unresolved exceptions. Expand the batch only after the accounting owner accepts the test outcome.

Expected result: The destination agrees with the source for the approved scope, and every exception has a named owner.

Keep this acceptance record with the 2026 configuration notes. It becomes the reference when permissions, mappings or the supported transfer method change.

Transfer payment updates without recreating invoices

An adjacent workflow is updating payment information after an invoice has already reached accounting. Treat payment updates as a separate operation, not another invoice export.

Use this variant only when the approved route supports the required update or payment operation:

1. Find the existing destination record through the stored source-to-destination reference.
2. Confirm that the event represents a settled payment rather than an expected payment or an unverified notification.
3. Apply the supported payment or status operation, preserving the payment reference and amount.
4. Reconcile the resulting balance and record the outcome separately from the original invoice transfer.

This separation makes failures easier to diagnose. An invoice can transfer successfully while a later payment update fails; retrying the invoice creation step is not the correct response.

For the Mesh App Lexoffice export workflow, keep invoice identity stable across both operations. A change to payment state must not become a new invoice simply because it arrives in a later batch.

Troubleshooting

The file is rejected before records appear

Compare the file against the current specification for the exact import operation. Check required fields, delimiter, encoding, date representation and decimal representation where applicable; changing the filename does not change the file structure.

The customer is wrong or duplicated

Inspect the matching rule and the source customer reference. Correct the mapping before retrying, and review existing destination records before creating another customer.

The totals do not agree

Compare the same documents in the same currency, then inspect tax treatment, net-versus-gross interpretation, signs and rounding. Do not alter a posted amount just to force agreement; resolve the underlying mapping with the accounting owner.

A retry creates a second record

Pause further submissions and identify which records already succeeded. Repair the transfer register, adopt a verified duplicate-control method and resolve duplicate accounting records through the approved correction process.

An automated run fails after working previously

Check access permissions, credential validity and the destination's current error response. Correct the stated cause before replaying anything, then retry only the records whose outcome is known to be unsuccessful.

Customize your workflow

Once the first handover reconciles, expand one dimension at a time: batch size, record types or execution frequency. Keep the approved field map unchanged while testing the next dimension so a failure has a clear starting point.

Schedule a review of the 2026 procedure whenever the source fields, destination requirements or accounting responsibilities change. Automation reduces repeated handling only when the exception queue remains visible and someone owns it.

FAQ

One last thing

Test the retry, not just the first transfer. A process that succeeds once but cannot distinguish completed records from failed records is not ready for unattended operation.

Keep the original payload, the destination references and the reconciliation result together. Those records give the next person enough evidence to resolve an exception without exporting everything again.

Related guides

• Moving from Excel to CRM without losing data
• E-invoicing requirements in Austria
• Finance and invoicing software for IT companies