Practical guide
From project time to invoice draft: a reviewable project-to-cash workflow
Several business decisions sit between “work completed” and “invoice sent”. A useful project-to-cash workflow connects them without turning time recording into an automatic final invoice.
What the route from project work to an invoice draft is really about
When hours are copied from several lists at month end, they often lose delivery context, approval state, or evidence that they were already billed. Fixed-fee and milestone projects need different triggers from hourly work. For professional services firms, agencies, and small project organisations, the deciding factor is therefore not the number of features but whether scattered information becomes a traceable workflow. A useful workflow answers four questions at any moment: what is the current state, who acts next, which basis was used, and what evidence shows that the work is actually complete?
The connection should use stable references rather than copies. Selected time or a billing-ready milestone becomes a locked basis; the invoice draft remains a separate controlled step in the invoicing product. Separating input, review, decision, and outcome prevents a polished dashboard from suggesting certainty that does not exist. It also makes corrections manageable. If an assumption was wrong, the whole case does not need to be reconstructed because the team can see where the decision happened and which information was available at that time.
A dependable workflow in clear steps
Do not begin with the longest possible checklist. Begin with the smallest complete run whose outcome is: Only selected, completed, reviewable work reaches an invoice draft that is then reviewed in Fakturen. Add exceptions and automation only after that route works from start to finish. This keeps the benefit of each step visible and exposes steps that merely create more maintenance.
For the route from project work to an invoice draft, a fixed order works well in day-to-day operations. Its first practical checkpoint is: Define billing model and verifiable delivery outcome on the project. Each further step creates a visible intermediate result and names the responsible role. Handoffs are never silently assumed. When information is missing, the state is “open” or “needs review”—never automatically “done”, “safe”, or “compliant”.
- 1. Define billing model and verifiable delivery outcome on the project.
- 2. Record time and milestones against the correct project.
- 3. Resolve open client decisions and mark only real approval as approval.
- 4. Select the billing basis and lock it against duplicate use.
- 5. Create a Fakturen draft and review recipient, tax, and delivery there.
The data and evidence that genuinely help
For the route from project work to an invoice draft, collect only information required for a concrete next action. The data model should support the outcome “Only selected, completed, reviewable work reaches an invoice draft that is then reviewed in Fakturen”, not merely offer the greatest number of fields. Every mandatory field therefore needs a defensible purpose. Free text is valuable for context, but it should not be the only source for amounts, dates, ownership, or status. Those facts belong in structured fields whose meaning is consistent for everyone involved.
A dependable record shows origin and freshness. Changeable rules need a review date and original source, internal decisions need an accountable role, and handoffs need a timestamp. Projektspiegel prepares a Fakturen draft; it does not automatically finalise or send an invoice. That is not a product weakness; it is an honest boundary between software assistance and human responsibility.
A practical quality check
Before releasing work on the route from project work to an invoice draft, use a short second-look moment. Begin with this domain check: Billing model and currency are unambiguous. Also verify the recipient, period, amounts, attachments, visibility, and expected next action. Ask whether somebody outside the immediate work could understand the result without an oral explanation. If not, the record usually lacks context or an unambiguous name.
The checklist below is intentionally shaped for professional services firms, agencies, and small project organisations. It can become a closing control in your own workflow and should be adapted to your organisation. Not every point applies in every case. For the route from project work to an invoice draft, the important habit is to show exceptions instead of hiding them behind broad defaults.
- Billing model and currency are unambiguous.
- Running or incomplete time entries are excluded.
- Every selection traces back to the project.
- A portal view is not acceptance.
- Cancelling or deleting a draft handles source records visibly.
Common failures—and why they become expensive
Failures in the route from project work to an invoice draft are rarely caused by one missing click. A particularly clear warning is: Treating every recorded hour as billable without review. Other failures grow from small gaps: a date exists only in email, an approval stays verbal, or two lists use different status words. Finding the truth later costs more than the original task. With external participants, the same gaps create avoidable questions and misunderstandings.
For professional services firms, agencies, and small project organisations, the patterns below are therefore not abstract best-practice warnings. They are concrete signals that the route from project work to an invoice draft lacks one source of truth or that preparation has been confused with an actual decision.
- Treating every recorded hour as billable without review.
- Billing a fixed fee and all time in full as well.
- Calling portal view, technical delivery, and business approval “seen”.
- Finalising an invoice outside the invoice-number authority.
Measure progress without metric theatre
Measure time from delivery completion to a complete billing basis and the number of items corrected before finalisation. A small set of stable measures is more useful than a dashboard full of percentages. Examples include cycle time, unresolved questions, the share of complete handoffs, and time to the next decision. Every measure needs a plain definition and visible reporting period.
For the route from project work to an invoice draft, first compare your own baseline with later weeks or months. Measure time from delivery completion to a complete billing basis and the number of items corrected before finalisation. Industry benchmarks are often incomparable because scope, team size, and definitions differ. Improvement is credible when it moves visibly toward “Only selected, completed, reviewable work reaches an invoice draft that is then reviewed in Fakturen”—not merely when the system records more clicks.
Privacy, roles, and safe handoffs
For the route from project work to an invoice draft, access should follow the job, not curiosity. People should see and change only the data required by their role. External links need finite expiry and immediate revocation. Projektspiegel prepares a Fakturen draft; it does not automatically finalise or send an invoice. Sensitive material does not belong in analytics parameters, URL fragments, unprotected exports, or broadly searchable notes.
Before automating anything around the route from project work to an invoice draft, define what happens when delivery fails. Network calls and messages need durable status, retries must be idempotent, and technical delivery is not the same as business approval. A system can help reach “Only selected, completed, reviewable work reaches an invoice draft that is then reviewed in Fakturen”; the organisation remains responsible for deciding which review and approval are necessary.
A useful way to start today
Choose one real but manageable case of the route from project work to an invoice draft and model it from beginning to end. Start with “Define billing model and verifiable delivery outcome on the project.”, then define ownership, inputs, review, outcome, and storage location. Use the model for one week, note every question, and change only what demonstrably causes friction. This creates a process the team understands instead of a theoretically perfect configuration.
Then document in a few sentences what “complete” means and which exceptions require a human decision. Only selected, completed, reviewable work reaches an invoice draft that is then reviewed in Fakturen. That is also how a tool should be judged: it should create clarity, make the next action easier, and leave existing accountability visible.
Questions and answers
Do I immediately need new software for the route from project work to an invoice draft?
Not necessarily. First define ownership, status words, and completion criteria. Software then helps the team apply that agreement consistently, expose changes, and simplify recurring handoffs.
Which step should not be automated?
A business or legal decision should not be inferred from incomplete data alone. Projektspiegel prepares a Fakturen draft; it does not automatically finalise or send an invoice. Automate preparation, reminders, and technical checks; let the accountable person confirm the decision.
How can I tell whether the process improved?
Look for fewer questions and less rework, shorter waiting time, and a higher share of fully completed cases. Measure the same clearly defined indicators before and after the change, and record exceptions.
What this article assumes and where it stops
Assumptions
- Project time is recorded daily or weekly and assigned to a customer.
- The invoice is created as a draft in Fakturen and checked by a person before finalisation.
Limits
- The workflow requires an organisation with both Studios; the draft is not an invoice in the tax sense.
- Hourly rates, VAT and service period remain input by the business itself.
Text last revised 2026-09-01, checked 2026-09-06.
Sources and further reading
General information, not legal, tax, payroll, or business advice. Check changing rules against the original source.
Try the project workflow interactively
Projektspiegel shows tasks, dates, time, decisions, and billing preparation with synthetic data only.
Try Projektspiegel