# PRD: AI-Assisted Invoicing
**Status:** Draft for discovery
**Target release:** TBD
**Proposed scope:** AI assistance for creating and reviewing invoices
> **Working assumptions:** The app serves small businesses and freelancers and already supports customers, invoice creation, and sending. This PRD proposes a focused MVP: helping users turn billing information into accurate invoice drafts. These assumptions and the numerical targets below require validation.
## 1. Summary
Add an AI assistant that helps users create invoices from plain-language instructions and supported documents, then flags potential issues before sending.
The assistant should reduce manual entry without taking control of financial decisions. **Users review and approve invoices before they are sent or finalized.** Existing manual workflows remain available.
**Example**
A user enters:
> “Create an invoice for Acme for 12 hours of design work at $100/hour, due in 30 days.”
Show the rest (198 more lines)
The assistant prepares a draft using the matching customer record, shows the interpreted line item and due date, and asks the user to resolve any ambiguity before proceeding.
## 2. Problem
Creating invoices often requires users to:
- Re-enter information from emails, notes, timesheets, or prior invoices.
- Find the correct customer, rates, and payment terms.
- Check for missing fields, duplicate charges, and calculation errors.
- Rewrite descriptions into clear, customer-facing language.
This work is repetitive and can delay billing. AI may reduce it, but incorrect financial details could undermine trust or cause monetary loss.
**Product principle:** Optimize for accurate, reviewable assistance—not maximum automation.
## 3. Goals and Non-Goals
### Goals
1. Reduce the time required to create a send-ready invoice.
2. Reduce repetitive data entry and avoidable omissions.
3. Make suggestions easy to inspect, edit, and reject.
4. Preserve user control over financial and customer-facing actions.
### Non-goals for MVP
- Autonomous sending, charging, refunds, or bank-detail changes.
- Tax, legal, or accounting advice.
- AI-generated tax calculations or arithmetic.
- Automated collections or payment-chasing campaigns.
- A general-purpose chatbot.
- Support for every document format, language, and jurisdiction.
## 4. Target Users and Jobs
| User | Job to be done |
|---|---|
| Freelancer | Convert a short description of completed work into an invoice. |
| Small-business owner | Create invoices from billing notes or timesheets with less typing. |
| Finance administrator | Review drafts for missing information and possible duplicates. |
**Primary user story**
> As a person responsible for billing, I want to describe or upload the work completed so that I can prepare an invoice quickly without losing control over its accuracy.
## 5. Proposed MVP
### A. Create a draft from text
Users can describe the customer, work, quantities, rates, and payment terms.
The assistant:
- Extracts structured invoice fields.
- Matches customers against records the user is authorized to access.
- Uses established account settings where applicable.
- Asks focused questions when required information is missing or ambiguous.
- Creates an editable draft.
It must not invent customer details, work performed, rates, or payment terms.
### B. Create a draft from an uploaded source
Support a limited, validated set of inputs, initially text-based PDFs and CSV timesheets.
The assistant:
- Extracts candidate line items and relevant billing details.
- Shows source references alongside extracted values.
- Marks unsupported or ambiguous fields as needing review.
- Clearly reports unreadable or unsupported files.
Scanned documents and OCR should be a later addition unless discovery shows they are essential.
### C. Review a draft
Flag potential issues such as:
- Missing required fields.
- Possible duplicate invoices or line items.
- Differences from an explicitly configured customer rate.
- Unresolved customer matches.
- Unclear line-item descriptions.
Warnings are advisory. Deterministic application rules remain authoritative for validation and calculations.
## 6. User Experience
1. User selects **Create with AI**.
2. User enters instructions or uploads a supported file.
3. The app returns a draft or asks for missing information.
4. A review view distinguishes:
- Information supplied by the user or source.
- Existing account or customer defaults.
- AI-suggested wording.
- Fields requiring confirmation.
5. User edits and approves the draft.
6. The existing send workflow performs its normal validation and confirmation.
**UX requirements**
- Preserve the user’s original input if generation fails.
- Allow users to reject suggestions and continue manually.
- Avoid presenting uncertain values as confirmed facts.
- Do not silently overwrite existing invoice fields.
- Keep “generate draft” separate from “send invoice.”
- Disclose that AI assistance can make mistakes.
## 7. Functional Requirements
| ID | Requirement | Priority |
|---|---|---|
| F1 | Convert supported input into a structured invoice draft. | Must |
| F2 | Restrict customer lookup and data access to existing user permissions. | Must |
| F3 | Ask for clarification rather than guessing critical financial fields. | Must |
| F4 | Use the application’s calculation engine for totals, taxes, discounts, and rounding. | Must |
| F5 | Require review before sending or finalizing an AI-created invoice. | Must |
| F6 | Show provenance for extracted or inherited critical fields. | Must |
| F7 | Validate model output against the invoice schema before saving. | Must |
| F8 | Record accepted AI changes in an audit history without unnecessarily retaining sensitive source content. | Must |
| F9 | Flag likely duplicates using existing invoice data. | Should |
| F10 | Suggest clearer descriptions without changing the underlying billing facts. | Should |
**Critical fields:** Customer identity, currency, quantities, rates, tax treatment, dates, and payment details.
## 8. Trust, Privacy, and Security
- Apply existing tenant isolation, access controls, encryption, and deletion policies.
- Send only the data necessary for the requested task to the model provider.
- Establish provider retention and training-use terms before launch; do not assume default terms are sufficient.
- Treat uploaded documents as untrusted data, not instructions. Document content must not grant permissions or trigger unrelated actions.
- Prevent the assistant from changing payment destinations or executing financial actions.
- Redact sensitive content from operational logs where feasible.
- Define source-file and model-interaction retention before rollout.
- Complete security, privacy, and relevant compliance reviews.
## 9. Success Metrics
**Primary metric:** Median active time from invoice creation start to send-ready draft.
Proposed pilot targets—not launch commitments:
| Metric | Initial target |
|---|---|
| Time to send-ready draft | At least 30% lower than a comparable manual workflow |
| Draft usefulness | At least 70% of generated drafts retained rather than discarded |
| Critical-field errors reaching sent invoices | No increase versus the manual baseline |
| User-reported usefulness | At least 80% positive among pilot respondents |
| Unauthorized sends or cross-tenant disclosure | Zero tolerance; any occurrence triggers incident review and rollout pause |
Also track corrections by field, clarification frequency, abandonment, latency, inference cost, and support contacts. Measure results by input type; a strong text-input result should not mask poor document extraction.
## 10. Evaluation and Acceptance Criteria
Build a representative, de-identified evaluation set covering:
- Complete and incomplete requests.
- Ambiguous customer names.
- Multiple currencies and date formats.
- Discounts, taxes, and rounding.
- Conflicting source information.
- Duplicate invoices.
- Malformed files and embedded malicious instructions.
**MVP acceptance criteria**
- Missing critical information is flagged rather than fabricated.
- Calculations come exclusively from the application engine.
- Invalid model outputs cannot create finalized invoices.
- Users cannot access another tenant’s data through the feature.
- Sending always requires an authorized user action.
- Failed requests preserve input and offer a manual fallback.
- Quality, latency, and cost thresholds are agreed before pilot expansion.
## 11. Rollout Plan
1. **Discovery:** Validate the highest-friction invoicing task and establish manual-workflow baselines.
2. **Internal testing:** Evaluate extraction, permissions, arithmetic boundaries, and failure handling.
3. **Opt-in pilot:** Release to a small cohort with explicit feedback collection.
4. **Limited availability:** Expand only after quality and operational gates are met.
5. **General availability:** Publish supported use cases and known limitations.
Use feature flags and a kill switch. Pause rollout for unauthorized actions, data isolation failures, or material deterioration in invoice accuracy.
## 12. Dependencies and Open Decisions
**Dependencies:** Structured invoice APIs, reliable customer records, deterministic validation, document parsing, model-provider agreement, observability, and evaluation tooling.
**Decisions required before implementation:**
- Which user segment and billing workflow have the greatest unmet need?
- Is text-to-invoice sufficient for MVP, or is document import essential?
- Which countries, currencies, and languages are supported?
- What data may leave the application’s hosting environment?
- What latency and per-invoice cost are acceptable?
- Who owns AI quality, incident response, and ongoing evaluation?
**Recommended next step:** Validate text-to-invoice with a small set of target users before committing to document extraction or broader automation.