Case: Fakturabehandling

Case: Byggematerialefirma sparede 500 timer/år på fakturabehandling

Problem:

Et distributionsfirma for byggematerialer havde:

12 forskellige fakturalinjer pr. ordre

Manuel matching af indkøbsordrer mod fakturaer

3 medarbejdere brugte 15 timer/uge på fejlrettelser

Vores tiltag:

1. Standardisering af fakturalinjer (Fra 12 → 3 kategorier)

Problem:
Fakturaer indeholdt overflødige detaljer:

6-8 linjer for emballagegebyrer (kasse, tape, polstring, etc.)
4 linjer for forskellige fragttyper
2 linjer for "diverse tillæg"

Løsning:
Vi implementerede en faktura-normaliseringsengine:

csharp

public class InvoiceNormalizer
{
    public NormalizedInvoice Normalize(SupplierInvoice rawInvoice)
    {
        return new NormalizedInvoice
        {
            Materials = SumAllMaterialLines(rawInvoice.Lines),
            Shipping = CalculateShippingTotal(rawInvoice.Lines),
            Surcharges = CalculateSurcharges(rawInvoice.Lines)
        };
    }

    private decimal SumAllMaterialLines(List<InvoiceLine> lines)
    {
        // Antager InvoiceLine har Amount og Category properties
        return lines.Where(l => l.Category == "MATERIAL")
                   .Sum(l => l.Amount);
    }
    // ... tilsvarende for Shipping og Surcharges
}

Effekt:

90% færre linjekonflikter ved matching

Enkelt sted at opdatere priser (ingen "jagten" på specifikke linjer)

Automatisk validering af afvigelser (f.eks. hvis "MATERIAL" beløb > ordreværdi)

2. Automatisk matching baseret på ordrenummer

Gammel proces:
Medarbejdere skulle manuelt:

Åbne ordresystem
Søge på leverandørnavn
Matche datoer og beløb

Ny løsning:
Vi byggede en faktura-auto-matcher med:

csharp

public async Task<MatchResult> MatchInvoiceAsync(string orderNumber, decimal amount)
{
    // Antager _orderRepo findes og har GetByNumberAsync
    var order = await _orderRepo.GetByNumberAsync(orderNumber);

    if (order == null)
        return MatchResult.NotFound();

    // Tolerance for 2% afvigelse i beløb
    // Antager order har TotalAmount property
    if (Math.Abs(order.TotalAmount - amount) > order.TotalAmount * 0.02m)
        return MatchResult.AmountMismatch();

    return MatchResult.Success(order);
}

Optimeringer:

Fuzzy matching på ordrenumre (f.eks. "PO-1234" ≡ "1234")

Automatisk valutaomregning for internationale ordrer

Machine learning til at identificere hyppige matching-mønstre

Resultat:

Fra 15 → 2 minutter pr. faktura

False positives < 0,5%

3. Én-kliks godkendelse for 80% af fakturaer

Flow:

flowchart

graph TD
    A[Faktura modtaget] --> B{Automatisk match?}
    B -->|Ja| C[Vis "Godkend" knap]
    B -->|Nej| D[Send til manuel review]
    C --> E[Log godkendelse i blockchain]

Teknisk implementering:

csharp

// Antager ASP.NET Core Controller kontekst
[HttpPost]
public async Task<IActionResult> ApproveInvoice(string invoiceId, [FromServices] IBlockchainService blockchain)
{
    // Antager _invoiceRepo findes
    var invoice = await _invoiceRepo.GetAsync(invoiceId);

    // Valider at fakturaen er klar til godkendelse
    // Antager Invoice har Status property og Approve metode
    if (invoice.Status != InvoiceStatus.PendingApproval)
        return BadRequest();

    // Gem uforanderlig transaktion
    // Antager IBlockchainService findes
    var txHash = await blockchain.LogApprovalAsync(
        invoiceId,
        User.Identity.Name, // Kræver bruger er logget ind
        DateTime.UtcNow
    );

    invoice.Approve(txHash);
    await _invoiceRepo.UpdateAsync(invoice);

    return Ok();
}

Sikkerhedsforanstaltninger:

Fire-and-forget arkitektur - Godkendelser behandles asynkront

Blockchain-audit trail - Uforfalskelig logning

Separat godkendelsesflow for fakturaer > 50.000 kr

Samlet virkning

Disse tiltag sammen bidrog til:

Tidsbesparelser:

Aktivitet	Før	Efter	Besparelse
Fakturabehandling	12 min	2 min	83%
Fejlrettelse	3 timer/uge	0,5 timer/uge	85%

Økonomi:

500 timer/år ⇨ ~375.000 kr sparet (ved 750 kr/time)

Reduceret cashflow-tid fra 45 → 22 dage

Nul papirfakturaer efter 6 måneder

Kvalitetsgevinster:

Leverandørers tilfredshed: +40%

Regnskabsfejl: Fra 5% → 0,8%

Hvorfor det virkede

Vi angreb kompleksiteten ved kilden (fakturalinjer) i stedet for at bygge komplekse workarounds

Brugte eksisterende data smartere (ordrenumre var allerede unikke nøgler)

Designet for "happy path" - optimerede 80% af tilfældene i stedet for at overengineere for edge cases

"Den største innovation var ikke teknologien - men at genoverveje, hvad der faktisk var nødvendigt at validere."