Forfis Blog

Category: Professional Services

  • 4-Week Invoice Processing Pilot for a 201-500 Employee Firm in Germany

    The Back-Office Bottleneck: Where Senior Hours Go to Die

    A 201-500 employee professional services firm in Germany processes 1,200 to 3,000 vendor invoices per month. Each invoice is received by email, printed or forwarded to a back-office clerk, manually entered into the ERP, and approved by a senior accountant. The average cycle time from receipt to payment entry is 3 to 5 business days. The error rate on data entry sits at 4 to 7%, meaning roughly 50 to 200 invoices per month require rework. Senior staff spend 12 to 18 hours per week on invoice review and correction, time that could go to client work or strategic planning. The pain is not the invoice itself; it is the friction between the document and the system of record, and the human cost of bridging that gap.

    Why Off-the-Shelf OCR and RPA Fall Short

    The first common approach is to buy an OCR tool and hope it works. Most OCR engines handle clean, structured invoices well but fail on the messy 20% that includes handwritten notes, multi-page documents, and vendor-specific layouts. The second approach is to hire more back-office staff. This adds cost without reducing cycle time, and it does not address the root cause: the manual handoff between document and ERP. The third approach is to build a custom RPA bot. RPA works for repetitive, rule-based tasks but breaks when the invoice format changes, and it requires constant maintenance. None of these approaches include a predictive layer that flags high-risk invoices for human review, so the senior accountant still reviews every single entry. The result is a system that is faster than manual entry but still slow, still error-prone, and still dependent on human attention for every transaction.

    The 4-Week Pilot: Extraction, Scoring, and Approval

    The pilot runs for 4 weeks and covers one invoice type, one ERP integration, and one approval channel. Week 1 is the process audit: map the current workflow, measure the baseline cycle time and error rate on a sample of 200 invoices, and identify the fields that the model must extract. Week 2 builds the extraction pipeline using the OpenAI API to parse the invoice and pull out vendor name, amount, tax, due date, and line items. The predictive scoring model is trained on the historical data from that invoice type to assign a risk score to each entry. Week 3 runs the model in shadow mode: it processes invoices in parallel with the human team, and the output is compared against the manual entries. Week 4 flips the switch to human-in-the-loop mode. The AI drafts the entry, the predictive model assigns a risk score, and if the score is below a threshold, the entry is auto-approved and pushed to the ERP. If the score is above the threshold, the entry is sent to a senior accountant via Slack or Microsoft Teams for one-click approval. Every decision is logged with a timestamp, the approver’s name, and the model’s confidence score.

    EU AI Act Compliance: What the Pilot Must Log

    The EU AI Act classifies invoice processing as a limited-risk use case under Article 6. The firm must maintain a record of the model’s intended purpose, document the human-in-the-loop approval step, and ensure the system does not make autonomous financial decisions. For a 201-500 employee firm in Germany, this means logging every AI-drafted invoice entry and the human who approved it, storing those logs for at least six years under the German commercial code, and providing a clear opt-out if a client disputes an automated classification. The predictive scoring model must be explainable: the firm must be able to state why a particular invoice was flagged for manual review. The OpenAI API’s output includes a confidence score for each extracted field, which serves as the basis for the risk score. The Slack or Teams integration provides a natural audit trail: every approval or rejection is timestamped and attributed to a named user. This satisfies the Act’s transparency requirement and gives the firm a defensible position in the event of a regulatory inquiry.

    How to Start: Five Concrete First Steps

    Step 1: Run the process audit. Identify the invoice type with the highest volume and error rate. Measure the baseline cycle time and error rate on a sample of 200 to 500 invoices. Step 2: Define the pilot scope. One invoice type, one ERP integration, one approval channel. Confirm that the ERP API is documented and accessible. Step 3: Build the extraction pipeline. Connect the OpenAI API to the invoice document store. Define the fields to extract and the validation rules. Step 4: Train the predictive scoring model. Use the historical data from the pilot invoice type to train a model that flags high-risk entries. Step 5: Configure the Slack or Teams integration. Set up the approval workflow so that senior accountants receive a notification with the extracted fields and a one-click approve/reject action. Step 6: Run the pilot in shadow mode for one week, then flip to human-in-the-loop mode for the remaining three weeks. Measure the cycle time and error rate at the end of week 4 and compare against the baseline.

  • On-Premise AI Lead Qualification for a Swiss Professional Services Firm

    The Problem: 52-Hour Response Gaps and 6-Hour Reporting Cycles

    A 51-200 person professional services firm in Switzerland faces a specific operational bottleneck: inbound inquiries arrive across time zones and channels, but the sales team works 09:00-17:00 CET, Monday through Friday. A lead that lands at 22:00 on a Thursday waits 52 hours for a first substantive reply. In B2B professional services, that gap is not a minor inconvenience; it is a measurable conversion loss. The firm’s CRM holds the pipeline data, its Notion workspace holds the methodology documents, pricing sheets, and case studies, and its monthly reporting cycle consumes roughly 6 analyst-hours per month assembling numbers that already exist in the CRM.

    The problem is not a lack of data. It is a lack of a system that reads the data, classifies the inquiry, drafts a response, and files the report without a human touching each step. The firm does not need a new CRM or a new helpdesk. It needs an intelligent layer that sits on top of the tools it already runs, operates around the clock, and keeps every data point inside its own infrastructure because Swiss data-protection expectations and GDPR Article 32 make off-premise processing of client and prospect data a compliance risk the firm is not willing to take.

    Mechanism: On-Premise RAG, Open-Weight LLM, and the CRM Integration Layer

    The architecture has three components: a retrieval-augmented generation (RAG) pipeline, a conversational agent, and a reporting module. All three run on the client’s own hardware.

    The RAG pipeline ingests documents from the firm’s Notion workspace via the Notion API (version 2022-06-28), which exposes pages and blocks as JSON. Documents are chunked at heading boundaries, embedded with a sentence-transformer model (e.g., all-MiniLM-L6-v2, 384-dimensional vectors), and stored in a local Qdrant instance. At query time, the agent retrieves the top-5 chunks, builds a prompt with the retrieved context, and calls an open-weight LLM—Llama 3 70B or Mistral 8x7B—running on the firm’s GPU server. No document content or query text leaves the building.

    The conversational agent classifies each inbound inquiry into tiers: high-intent, mid-intent, low-intent. High-intent leads are routed to the CRM via its REST API with a structured summary. A human reviews every high-intent classification before the CRM record is created. The reporting module ingests CRM pipeline data and the firm’s Notion templates, drafts a structured monthly report with variance analysis, and queues it for human approval.

    The model-agnostic design means the firm can swap the LLM backend if a newer open-weight model outperforms the current one, without changing the RAG pipeline or the CRM integration.

    Trade-offs: Model Quality, Human Oversight, and Timeline

    The first trade-off is model quality versus data residency. A frontier API model (GPT-4o, Claude 3.5 Sonnet) would produce more nuanced lead classifications and better report narratives. But sending prospect names, firm details, and inquiry text to a third-party API violates the firm’s data-residency policy and complicates the GDPR Article 28 processor assessment. The open-weight model on-premise trades roughly 10-15% in classification accuracy for full data control. For a 51-200 person firm where the sales team reviews every high-intent lead anyway, that accuracy gap is acceptable.

    The second trade-off is the human-in-the-loop gate. Every high-intent classification requires a human approval before the CRM record is created. This adds roughly 90 seconds per lead and means the agent cannot fully automate the pipeline. But it eliminates the risk of a misqualified lead consuming a senior consultant’s time, and it satisfies the firm’s internal governance requirement that no AI output touches the sales pipeline without human sign-off.

    The third trade-off is the 4-week timeline. A full production rollout with monitoring, alerting, and a second channel would take 8-10 weeks. The 4-week pilot scopes to one workflow—lead qualification from inbound inquiries—and ships with a measured before/after baseline on cycle time and error rate. The firm accepts a narrower scope in exchange for a faster proof of value.

    Recommendation: Scope the Pilot to One Workflow, Measure the Delta

    The pilot targets lead qualification from inbound inquiries. The process audit in Week 1 maps the current workflow: inquiries arrive via email, web form, and phone, a sales associate manually classifies each one, drafts a first response, and logs the lead in the CRM. The baseline measurement captures cycle time (median 38 hours from inquiry to first response) and error rate (12% of leads misclassified in the prior quarter).

    Week 2 builds the RAG pipeline and connects the Notion API. Week 3 runs the agent in shadow mode against 200 historical inquiries, comparing its classifications to the human baseline. Week 4 adds the approval gate, connects the CRM write path, and measures the after-state. The target: reduce median first-response time to under 15 minutes for round-the-clock inquiries, and reduce misclassification rate to under 5%.

    The monthly reporting module ships in the same pilot. It ingests CRM pipeline data and the firm’s Notion reporting templates, drafts the monthly report, and queues it for analyst review. The target: reduce assembly time from 6 hours to 45 minutes of review and editing.

    The dedicated AI team operates as an embedded unit. The firm’s engineers and operations staff work alongside the team daily, not through a ticketing queue. This matters for a 4-week timeline: the team needs direct access to the Notion workspace, the CRM API credentials, and the firm’s GPU server, and it needs the operations staff available for the shadow-mode testing in Week 3.