Harvest e-invoicing: check invoice PDFs | ValiMesh

Harvest invoices as XRechnung or ZUGFeRD: why the last mile matters

For many service providers, Harvest can remain the billing system. What matters is not replacing the system, but finding a clean path from the existing invoice output to a validated e-invoice for Germany.

Intro

For many professional-services teams, Harvest is a familiar place: tracking time, bundling project work, accounting for expenses, creating invoices, and making the next payment step as easy as possible for clients. That is exactly why replacing the billing system is often the wrong first reaction when German e-invoicing comes up.

The better question is this: Can Harvest remain the operational front end while the final invoice output is enhanced so that it becomes a valid XRechnung or ZUGFeRD file? For many teams, that is the more pragmatic route. It protects the existing workflow and focuses the change where it is actually needed: format, validation, and handoff.

A fair distinction is important. Harvest is not a pure PDF system. Based on currently available public documentation, Harvest supports UBL exports and Peppol preparation. That makes the situation more interesting, not necessarily simpler. The need shifts: the question is not how to make Harvest “e-invoicing capable.” The question is how to solve the German target output and the concrete validation path cleanly.

Why Harvest can stay

In many companies, Harvest is not just an invoice form. It is part of the operating rhythm. Project time, costs, fixed fees, and service descriptions are created where the team already works. Replacing that process can create new friction: different fields, new approvals, unfamiliar invoice logic, and additional coordination between operations, finance, and project leads.

ValiMesh therefore does not start by replacing the source system. Harvest remains the place where the invoice originates. The change happens only on the last mile: the existing invoice output is turned into a structured, validated target output for XRechnung or ZUGFeRD. This is especially relevant for teams that do not want to rebuild their billing process, but still need a robust route for German B2B requirements and recipient workflows.

The benefit of this perspective is that the implementation becomes smaller. Instead of starting a large ERP or accounting project, the process begins with one real Harvest invoice PDF. That document shows which fields are present, how line items are structured, whether tax, service periods, customer data, and references are clearly visible, and which activation path is realistic.

Where the output gap appears

An invoice can be factually correct and visually clean while still not being the structured target output that a German e-invoicing process requires. A PDF is easy for humans to read, but it is not automatically a structured dataset. With XRechnung and ZUGFeRD, the machine-readable part matters: mandatory information must be present in the structured file correctly, completely, and in a logically validatable form.

Harvest has a special characteristic here. The platform already contains structured invoice data and can export UBL XML. Harvest can also prepare e-invoices for an external Peppol route. That is strong, but it is not identical to every German target requirement. If a recipient expects XRechnung, a specific ZUGFeRD profile, certain references, or a particular validation logic, the output needs to be checked in the concrete case.

So the gap is not “Harvest can only do PDF.” The gap is: does the concrete Harvest invoice output fit the German final mile? Are the data fields complete enough? Is the desired target format generated? Does the file pass meaningful validation? And how can the recurring process be set up without manual XML work every time?

How ValiMesh solves the last mile

ValiMesh is positioned as an output and validation layer. It does not replace Harvest, but uses the existing invoice output as the starting point. The simplest entry point is a real Harvest invoice PDF. This PDF shows how the current process actually looks — not how it might appear in an idealized field list.

Based on that document, ValiMesh checks whether the route is immediately workable or whether a layout first needs to be activated. For a new layout, the typical activation time is around two business days. After that, the recurring output toward XRechnung or ZUGFeRD can be stabilized. The target is a clear flow: Harvest remains in front, and ValiMesh adds the structured target output at the end.

For teams with higher volume, the automation layer can then be assessed. Harvest provides structured invoice data through API and exports. These data points can become relevant for recurring processes once it is clear which fields are needed and which target standard actually works for the recipient. The PDF-first approach does not contradict the API route. It is the fastest reality check before automation.

What is checked with a real PDF

A real Harvest PDF answers questions that often remain open in abstract integration discussions. Are invoice number, customer data, seller data, service date, payment terms, and tax logic clearly identifiable? Are line items individually structured, or merged into longer descriptions? Are there time records, expenses, fixed fees, or attachments? Is the service description suitable for the structured part, or are additional details needed?

ValiMesh also checks whether the layout is already known or needs activation. This distinction matters: an approved layout can be used repeatedly. A new layout first needs a fit check, activation, and acceptance. This creates clear expectations. The promise is not that any arbitrary PDF can automatically go live immediately. The question is which path is reliable for this specific document.

The result is a validation report. It shows whether the path to XRechnung or ZUGFeRD is plausible, which data points are especially important, and whether structured Harvest data could help later. That turns a large compliance topic into a small, testable next step.

When structured data, API, or workflows become relevant

For a single invoice, the PDF test is often enough as an entry point. With recurring volume, the question becomes larger: how does the output regularly reach ValiMesh? Is a PDF uploaded, exported, or handed over through a workflow? Are API data used to transfer fields more reliably? Is there a partner who supports the Harvest process and rollout?

Harvest is interesting here because structured invoice data already exists. The API contains invoice objects, line items, client references, amounts, currency, due dates, and status information. That can support later automation. Still, this layer should only be decided after the target output has been assessed. An API connection does not automatically answer whether the target-format output is correctly validated, recipient-ready, and process-safe.

The sensible sequence is therefore: first check a real PDF, then define target format and validation, then evaluate recurring handoff and automation. This keeps the project small enough for a fast start and robust enough for productive use.

Conclusion

Harvest does not need to be replaced reflexively because of German e-invoicing. For many teams, Harvest is the right place for invoice preparation, project billing, and client communication. The open question sits on the last mile: how does the existing invoice output become a valid XRechnung or ZUGFeRD file that fits the German target process?

ValiMesh answers this question with a PDF-first approach. One real Harvest PDF is checked, the layout is activated if needed, and the target output is structurally validated. Where useful, API data, exports, or workflow steps can be added later. That way, Harvest remains at the core — and the German e-invoice output gets the specialized layer it needs.