Hold fakturaopfølgningen tæt på dine eksisterende oplysninger.

Start i det system, der holder styr på saldoen

Fakturaopfølgning kræver mere end kundens e-mailadresse. Den, der forbereder en påmindelse, skal kende fakturanummer, forfaldsdato, valuta, restbeløb og eventuelle grunde til at sætte opfølgningen på pause. Oplysningerne skal komme fra en aftalt regnskabskilde. En kontakt, der er eksporteret efter en salgshenvendelse, fortæller ikke, om der er udstedt eller betalt en faktura.

Procoras egen abonnementsbetaling handler om, hvad virksomheden betaler for Procora. Den er adskilt fra de beløb, virksomhedens kunder skylder. En forbindelse til det ene giver ikke adgang til det andet. Den foreslåede tjeneste skal organisere opfølgning på eksisterende oplysninger; den skal ikke erstatte bogføring, oprette fakturaer eller ændre regnskabet.

Hvad de eksisterende forbindelser faktisk gør

Den eksisterende e-conomic-forbindelse eksporterer oplysninger fra henvendelser til kundeposter. Den leverer ikke en verificeret strøm af fakturaer, kreditnotaer eller betalinger til denne tjeneste. Dinero og Billy står i forbindelsesoversigten som muligheder for kontakteksport gennem automatisering. Placeringen i oversigten dokumenterer ikke synkronisering af tilgodehavender. Det er vigtigt at skelne mellem funktionerne, når en eksisterende Procora-opsætning vurderes.

En fakturaforbindelse til Xero eller QuickBooks er ikke verificeret i Procora. Navnene angiver systemer, som en virksomhed kan bede os vurdere, ikke integrationer, der er klar til brug. Funktionstabellen adskiller eksisterende kontaktarbejde fra fakturaadgang, der kræver udvikling. En fremtidig forbindelse skal have sin egen adgangsvurdering, feltmapping og test, før den kan bruges til påmindelser.

Aftal oplysningerne før automatiseringen

En foreslået import kræver et stabilt faktura-id, kunde-id, faktura- og forfaldsdato, valuta, bruttobeløb, anvendte kreditnotaer, fordelte betalinger og restbeløb. Godkendte kontaktpersoner, fakturastatus, indsigelser og tidspunktet for seneste kildeopdatering er også vigtige. En ansvarlig person skal bekræfte, hvordan hvert felt findes, og hvad et tomt eller manglende felt betyder.

Begynd så vidt muligt med læseadgang. Tilladte ændringer skal beskrives særskilt; adgang til at læse fakturaer giver ikke ret til at ændre vilkår, bankoplysninger eller saldi. Medtag kun poster inden for den aftalte virksomhed, valuta og periode. Brug kildens id’er til at genkende opdateringer, så en gentagen eksport ikke bliver til en ny faktura, og undgå at identificere poster alene ud fra kundenavnet.

Et øjebliksbillede og en løbende forbindelse kræver forskellige regler

Et regneark, der afleveres manuelt, viser situationen på et bestemt tidspunkt. Det kan ikke fortælle om en betaling, der kommer bagefter. En aftalt løbende forbindelse skal opdatere oplysninger med angivne intervaller; forsinkelser og fejlede opdateringer kan stadig forekomme. Procora tilbyder ikke i dag en verificeret fakturaimport eller løbende betalingssynkronisering til denne planlagte tjeneste. Begge metoder kræver udvikling og validering.

I den foreslåede arbejdsgang skal både kildens dato og tidspunktet for seneste kontrol vises ved fakturaen. Aftal, hvornår oplysningerne er for gamle til en påmindelse. Hvis grænsen er overskredet, skal næste handling være en kontrol hos den ansvarlige frem for en besked baseret på en gammel saldo. En opdatering af posten må ikke uden videre fjerne en uafklaret indsigelse.

Eksempel: En kreditnota og en betaling er forskellige hændelser

Den fiktive faktura EX-103 er på £2,000. En anvendt kreditnota på £200 reducerer det skyldige beløb, og en fordelt betaling på £1,800 afregner resten. Restbeløbet er £0. En korrekt feltmapping holder hændelserne adskilt: £1,800 er betalt, mens £200 er krediteret. Det ville være forkert at rapportere £2,000 som modtagne penge.

EX-101 har stadig et restbeløb på £900 efter en delbetaling på £300. Et kundesvar med teksten “betalt” er nyttig information, men er ikke en betalingspost. Den foreslåede arbejdsgang sætter almindelige påmindelser på pause og beder om kontrol. Det offentlige eksempel afslutter først restbeløbet efter en simuleret betalingsfordeling; det kontrollerer aldrig en bank og behandler ingen rigtige penge.

Hvad sker der, hvis opdateringer fejler, eller adgangen fjernes?

En fejlet opdatering skal være synlig for den kildeansvarlige. Bevar tidspunktet for seneste vellykkede opdatering, og forklar, hvilke fakturaer der kan være berørt. En kendt saldo må ikke erstattes med nul, fordi en forespørgsel fejlede eller gav ufuldstændige oplysninger. En afbrudt forbindelse skal stoppe brugen af denne kilde og sætte afhængige påmindelser på pause, indtil en bemyndiget person bekræfter næste sikre skridt.

Tag navnet på dit regnskabssystem, de nødvendige fakturatyper og din nuværende opfølgningsproces med til en afgrænsningssamtale. Send ikke adgangsoplysninger eller kundefiler gennem den offentlige formular. Vi kan beskrive den adgang, udvikling og kontrol, et muligt pilotforløb kræver, før der gives tilsagn om en forbindelse eller en aktiveringsdato.

Udforsk eksemplet