Geautomatiseerd verwerken van facturen (3)

In dit artikel wil ik weer een update geven van onze ervaringen tijdens het selectieproces van een geschikte oplossing voor het geautomatiseerd verwerken van facturen. Na een eerste demo door vier potentiële leveranciers hebben we er uiteindelijk voorlopig één uitgenodigd voor een tweede demo.

Die hebben we onlangs gehad en daarbij hebben we geconstateerd, dat het toch nog wat meer voeten in de aarde heeft op enkele punten, dan we naar aanleiding van de eerste demoronde hadden ingeschat. Dit speelt overigens vooral in de wat complexere administraties en dan met name bij de faturen, die moeten worden geboekt op meerdere grootboekrekeningen en/of kostenplaatsen. Meestal staat er namelijk geen kostenplaatscode op de factuur vermeld, maar bijv. een vestigingsplaats, medewerkernaam of kenteken. De te behalen efficiency is echter wel voor een behoorlijk deel afhankelijk van de mate waarin dit soort facturen automatisch worden verwerkt, omdat dit handmatig de meeste tijd kosten.

Verder is de koppeling naar het financiële pakket ook van wezenlijke invloed op het verwerkingsproces. Tijdens de demo constateerden we bijv. dat het tijdens de demo gebruikte pakket de BTW-code gebruikte en aan de hand daarvan het BTW-bedrag zelf berekende. Met het BTW-bedrag van de factuur werd dus niets gedaan. Als deze BTW-bedragen niet overeenkwamen, kon de boeking niet worden gemaakt, omdat deze niet in evenwicht was. Dit gaat fout in de volgende situaties:

  • BTW-bedrag wordt per factuurregel berekend: doordat de afronding dan ook per regel plaatsvindt, kan het totaal van de regelbedragen, zeker bij veel factuurregels (bijv. brandstofnota) afwijken van de totaalberekening. In het voorbeeld ging het om € 0,41 op de 180 factuurregels;
  • Gedeelte van de factuur is vrijgesteld van BTW: er staat dan maar één BTW-bedrag op de factuur, maar dat is geen 19% van het totaalbedrag excl. BTW;
  • Bedrag excl. BTW staat op de factuur niet gesplitst in grondslag tegen hoog en grondslag tegen laag tarief, maar het BTW-bedrag wel.

In het financiële pakket was afwijking wel mogelijk, door dit aan te vinken in een speciaal daarvoor bedoeld veld. De koppeling moet dus ook zo worden aangepast, dat de controle wel blijft, maar dat het mogelijk is om het BTW-bedrag af te laten wijken van wat het op basis van de gekozen code zou moeten zijn, eventueel binnen ingestelde grenzen.

Het te behalen resultaat is dus voor een heel groot deel afhankelijk van de kwaliteit van de facturen. Op zich een open deur, maar zeker in een traject als dit, blijkt dat overduidelijk. Eén van de dingen die we bijv. voor het handmatig verwerken al hebben gedaan, is het op de factuur laten vermelden van de kostenplaats op de brandstofnota. Voor het automatisch verwerken blijkt dit nu niet alleen handig te zijn, maar zelfs cruciaal om handmatig werk te voorkomen. Dit moeten we dus nog door (veel) meer crediteuren laten doen.

Aan de hand van de niet in één keer volledig herkende facturen gaan we nu onze crediteurenadministratie op een aantal punten nog verder analyseren vóór we definitief een beslissing nemen over de te kiezen oplossing en de wijze van implementatie.

Verder hebben we tijdens de demo ook een stukje van het proces van het scannen, scheiden van meerdere facturen uit één bestand, e.d. gezien, waardoor mijn beeld van de logistiek rondom de facturen (met name voor administraties van cliënten) weer een stuk duidelijker is geworden. Tijdens de demo duurde dit deel eigenlijk iets te lang, doordat de techniek ons een beetje in de steek liet, maar inhoudelijk was het mij die tijd wel waard.

Advertenties

Geautomatiseerd verwerken van facturen (2)

Geautomatiseerd verwerken van facturen blijkt een ontwikkeling te zijn waar heel veel mogelijk is, maar wat ook behoorlijk veel zaken kent, waar de leveranciers tijdens gesprekken geen aandacht aan schenken en die toch zeker relevant zijn. Inmiddels heb ik van vier potentiële aanbieders een demo gehad en een voorstel hoe ze de oplossing voor onze organisatie in zouden vullen. Hierbij blijkt ook weer dat het vooraf definiëren van de eisen, wensen en randvoorwaarden bepaald geen overbodige luxe is. De oplossing die er in de demo het mooist uit zag, voldoet namelijk wel aan veel wensen, maar niet aan alle eisen.

Voor onze interne organisatie is het belangrijkste verschil tussen de geboden oplossingen de regelherkenning op facturen. Aangezien wij veel facturen verdelen over diverse kostenplaatsen, is dit een relevant punt om een hoog percentage te gaan scoren voor het automatisch verwerken. Bij alle aanbieders is te zien, dat ze in de markt van de grotere organisaties goed thuis zijn. Overigens was dit ook te merken aan de standaardkoppeling die bijna alle aanbieders hadden naar onze ERP applicatie.

In de accountancymarkt hebben we nog een uitdaging: geautomatiseerde verwerking van de administraties van cliënten. In tegenstelling tot onze interne organisatie met weinig administraties en relatief veel facturen per administratie praten we hier over veel administraties met relatief weinig facturen per administratie. Daarnaast moeten onze cliënten het naar keuze op papier of digitaal aan kunnen leveren en daar zit de grootste uitdaging, die we zeker op gaan lossen. Een voorbeeld van zaken om rekening mee te houden:

  • Cliënten ontvangen digitale facturen, die direct moeten kunnen worden doorgestuurd voor verwerking in hun administratie;
  • Of nog beter: wij bieden de cliënten een digitale facturenpostbus, waar ze hun leveranciers de facturen rechtstreeks heen kunnen laten sturen (maar hoe gaat het dan met de accordering van de facturen door de cliënt; nu krijgen we ze in de praktijk pas als de cliënt ze akkoord vindt);
  • Digitale facturen kunnen op dit moment zowel pdf- als xml-berichten zijn;
  • Cliënten scannen facturen van wisselende aantallen pagina’s in wisselende aantallen facturen per scanopdracht.

Voor kleine ondernemingen is er nog een andere oplossing, die in onlangs voor het eerst heb gezien: Yuki. Eigenlijk is dit een boekhoudpakket, waarin de gebruikers alleen nog maar documenten zien (facturen, bankafschriften, e.d.) en geen journaalposten. Hier hoop ik binnenkort nog een afzonderlijk stukje over te schrijven, want dat is het zeker waard.

Geautomatiseerd verwerken van facturen

Digitaal factureren is al een tijdje een hot item. Hierbij gaat het vrijwel altijd over het verzenden van facturen. Maar hoe zit het met het verwerken ervan, dus aan de ontvangende kant? Het lijkt me niet overdreven om te stellen, dat het daar momenteel meestal voor minder efficiency zorgt door twee processen naast elkaar (papier en digitaal) of dat de factuur daar ‘gewoon’ wordt geprint en op dezelfde manier wordt verwerkt als de facturen die op papier zijn ontvangen.

Mijn ervaring is, dat digitale facturen nogal eens worden verzonden in pdf-formaat, wat het gemakkelijk verwerken niet echt bevordert. Ook documenten uit een tekstverwerker of een spreadsheet komen voor, wat nog dramatischer is. Een gestandaardiseerd xml-bericht (bijv. UBL 2.0) ontbreekt vrijwel altijd, waardoor directe verwerking in de crediteurenadministratie niet kan.

Meestal wordt zo’n factuur daarom op de gebruikelijke manier handmatig geboekt. Om zo’n factuur te kunnen boeken in een financiële administratie heb je op z’n minst twee monitoren nodig als je de benodigde verwerkingstijd niet toe wilt laten nemen door eindeloos wisselen tussen de vensters met de factuur en de financiële applicatie.

Momenteel ben ik bezig om een oplossing te zoeken, waarmee beide factuurstromen kunnen worden gescand, herkend en automatisch geboekt in de crediteurenadministratie. De tijd dat alle facturen digitaal volgens standaarden worden uitgewisseld, ligt naar mijn idee nog wel een aantal jaren weg, dus tijd investeren in geautomatiseerde verwerking van papieren en pdf-facturen is zeker zinvol als dit op korte termijn gebeurt. Tot die tijd lijkt mij de beste oplossing het digitaliseren van alle facturen, die op papier binnen komen en het tot standaardproces verheffen van het verwerken van deze gedigitaliseerde stroom.

Inmiddels ben ik er wel achter, dat er goede oplossingen beschikbaar zijn om dit mogelijk te maken. Kostentechnisch lijkt het ook zeker interessant. Voor m’n vakantie hoop ik voor onze eigen organisatie nog een berekening hiervan te maken. De collega’s, die inkoopfacturen verwerken, hebben gedurende een maand precies geregistreerd hoeveel tijd ze daaraan kwijt zijn, dus een reële berekening gaat vast lukken.

Uitdagingen zijn er ook:

  • Hoe verwerken we pdf-bestanden, waarin meerdere facturen zijn opgenomen? Papieren facturen worden verwerkt met bijv. een barcodesticker, maar in pdf-bestanden kan dat uiteraard niet.
  • Hoe verwerken we facturen, die betrekking hebben op een langere periode (abonnementen, verzekeringen, e.d.) direct als transitorische post in de financiële administratie? Dit is van groot belang voor realistische exploitatieoverzichten.
  • Kan de digitale factuur worden opgeslagen in het dossier van de crediteur, zodat alle belanghebbende medewerkers er via de gebruikelijke applicatie bij kunnen zonder een extra archiefapplicatie te moeten gebruiken?
  • Kan de oplossing overweg met meerdere administraties? Als accountantskantoor willen we deze oplossing ook voor onze cliënten kunnen gebruiken, dus dit punt is van niet de onderschatten belang.

Als ik weet welke oplossing we gaan kiezen, hoop ik hier zeker nog een vervolg te plaatsen.

%d bloggers liken dit: