Når man flytter sin abonnementsstyring til Iteras opstår der en række spørgsmål, som er specielle for overgangsperioden mellem to systemer. Hvad foretager man sig i sit gamle system lige før overgangen – skal man f.eks. vente med at fakturere de abonnenter, der er modne til fakturering, til efter skiftet? Hvad sker der, når en kunde efter skiftet betaler en faktura fra det gamle system? Hvordan håndteres stop af abonnementsperioder, der involverer kreditering af fakturaer fra det gamle system? Disse spørgsmål er emnet for denne artikel.

Bemærk, at der kan være forskel på den måde, som data importeres på til Iteras, og derfor kan der være variationer til de følgende principper.

Fakturering op til skiftet

Hvis man i en periode – en måned ville være oplagt – før skiftet kan vente med at fakturere faktureringsmodne abonnementer til efter skiftet til Iteras, vil dette som regel være en god idé. Det betyder, at perioden hvor der kommer betalinger ind på fakturaer udstedt af det gamle system efter skiftet til Iteras, bliver kortere, og der bliver færre betalinger at håndtere manuelt. Iteras registrerer jo alle betalinger automatisk efter skiftet, og betalinger som er udstedt af det gamle system vil derfor fejle, idet vi ikke kender betalings-id’en i Iteras. Disse kan så eksporteres som csv-fil, og indlæses eller indtastes i det gamle system.

Fakturaer fra det gamle system betales i det gamle system

Fakturaer som er oprettet i det gamle system, skal rykkes færdig i det gamle system. Iteras tager som givet, at for de abonnementer der migreres til Iteras, er den igangværende periode betalt.

Hvis fakturaer fra det gamle system viser sig uerholdelige, dvs. aldrig at blive betalt, krediteres de i det gamle system, og abonnementet stoppes manuelt i Iteras.

Information om faktureret, krediteret og betalt flyttes til Iteras

Beløb som er faktureret, krediteret og betalt på den igangværende periode importeres med til Iteras. På baggrund heraf kan Iteras kreditere det korrekte beløb, når igangværende abonnementer stoppes før udløb. Læs mere om, hvordan denne kreditering kan ske her.

Der vil typisk være en bunke udsendte men ubetalte fakturaer på overgangstidspunktet. For disse er der to muligheder hvad oplysning om betaling angår:

  • Man importerer dem som ikke betalte. Derved vil der ved et stop af abonnementet i Iteras ikke blive frigjort et beløb, som kan tilbagebetales til kunden – dvs. det korrekte som skal ske. Imidlertid vil mange abonnenter som ikke har betalt på overgangspunktet, betale deres faktura efter overgangstidspunktet. Dette registreres som nævnt i det gamle system, men hvis denne løsning vælges, vil man tillige skulle opdatere oplysninger om betalingen i Iteras.
  • Hvis det af en eller anden årsag er upraktisk at opdatere Iteras med oplysninger om de daglige betalinger for fakturaer fra det tidligere system i perioden lige efter overgangen, kan man i stedet vælge at føre antagelsen om, at alle abonnementer der migreres er betalt, helt ud i livet, og registrere dem som betalt med et beløb der svarer til fakturabeløbet – også selv om de reelt ikke er betalt. Dette har den ulempe, at stopfunktionen ved stop vil nå frem til, at der er betalt et beløb, som kan tilbageføres til kunden, men det kan i nogle tilfælde være forkert. Man kan så enten vælge at tage dette som et – formentlig mindre – tab, eller man kan lave en løsning, hvor man registrerer manglende betaling i et customfelt, som man så opdaterer med indkommende betalinger (idet customfelter er nemmere at opdatere ved import eller API end økonomifelter, hvor informationen om betaling normalt lægges). Hvis man heller ikke kan opdatere customfeltet, har man dog reduceret antallet af abonnementer, hvor man manuelt må se efter i det gamle system om der er betalt eller ej, til det antal der var ubetalt på overgangstidspunktet (statistisk set omkring 1/12). Da ubetalte fakturaer som regel afklares inden for den første måneds tid, vil denne overgangsprocedure kun skulle køre kortvarigt.

Stop af betalt abonnement fra det gamle system

Når et abonnement, som er faktureret og betalt i det gamle system, stoppes i Iteras (hvilket efter overgangen kan ske i en periode så lang som det længste abonnement), sørger Iteras’ stopfunktion for at for at beregne det korrekt beløb som skal krediteres, ud fra de svar der gives på, hvornår abonnementet skal stoppes, og hvornår der skal betales til. Bemærk, at oplysningen om betaling er afgørende for, hvad stopfunktionen beregner af kreditering. Se mere under punktet overfor.

Stop af ikke betalt abonnement fra det gamle system

En anden situation er når et abonnement, som er faktureret men ikke betalt i det gamle system, stoppes i Iteras. Da man typisk får rykket færdig på fakturaerne fra det gamle system i løbet af den første måned efter overgangen til Iteras, vil dette kun forekomme i den første tid.

Det er en særlig problematik, at abonnementet og dermed leveringen er i gang. Hvis der er tale om fysiske produkter (og ikke f.eks. “bare” en digital adgang), har der været omkostninger forbundet med leveringen af produktet til kunden. Uanset om der har eller ikke har været omkostninger, vil udgiverens holdning ofte være, at der skal betales for den leverede periode. Mediers politik på området varierer, men Iteras vil ofte kreditere restperioden, og gensende en opdateret betalingsanvisning, hvor det krediterede beløb fremgår som fratrukket det oprindeligt fakturerede beløb. Dette understøttes imidlertid ikke, når Iteras ikke har oprettet fakturaen.

Derfor er løsningen, at der laves et manuelt stop med fuld kreditering, hvis man ikke har lagt indbetalingen ind. Hvis man derimod har valgt at lægge en betaling ind på alle, også dem der ikke har betalt, må man lave et stop uden kreditering, og så lave krediteringen i det gamle system. Dernæst laver man manuelt en faktura på den leverede periode, hvor beløbet beregnes manuelt for den periode, der er leveret i fh.t. det totale fakturabeløb.