Paraşüt integration: invoice and current-account automation

Every won deal at a Turkish small business tends to trigger the same quiet ritual. Someone opens the pre-accounting software, searches for the customer or creates them from scratch, re-types the tax number, address and the agreed amount, and raises an invoice by hand. The information already exists in the CRM, captured once when the lead first arrived and refined through every call, quote and meeting since. It simply is not where the accountant needs it, so a person becomes the copy-paste bridge between two systems that were never introduced to each other.

That bridge is exactly where hours and accuracy drain away. Names get misspelled, a digit falls out of a tax number, an invoice goes out against last quarter's address, and the sales rep has no idea whether the customer was ever actually billed. Connecting Rocketly to Paraşüt, the pre-accounting product a huge number of Turkish businesses already run, removes the bridge entirely: the contact, the current account and the invoice travel between the two systems on rails instead of on someone's memory. This guide walks through how that integration should be designed, what belongs in which direction, and how to switch it on cleanly.

Rocketly +ParaşütContactsCurrent accountsInvoicese-Invoice, paymen…

Why the sales-to-invoice gap costs more than it looks

The obvious cost of manual re-entry is time: a couple of minutes per invoice feels trivial until you multiply it by every order, every month. The hidden cost is worse. Each manual hop is a chance to introduce an error, and finance errors do not stay small. A wrong tax number means a rejected e-Invoice. A mistyped amount means a credit note, an awkward phone call, and a customer who now trusts your paperwork a little less.

There is also a visibility cost: when invoicing lives in a separate silo, salespeople cannot see whether a deal has been billed or paid, and end up chasing finance instead of revenue. Unbilled work, forgotten renewals and quietly dropped line items are a classic form of revenue leakage: money you earned but never collected because the handoff between selling and billing was a person, not a process. Closing that gap is the real reason to integrate, not the few minutes saved per document.

One-way or two-way sync? Decide deliberately

The single most important design choice is the direction of the sync, and it is worth making on purpose rather than accepting whatever the default happens to be.

One-way (CRM to Paraşüt)

In a one-way setup, Rocketly is the source of truth for who the customer is and what they bought, and it pushes that data into Paraşüt to raise documents. Paraşüt does not push anything back. This is the simplest, safest place to start: sales owns the relationship, pre-accounting owns the ledger, and data flows in a single, predictable direction. The trade-off is that payment status and accounting-side edits stay inside Paraşüt unless you go and look.

Two-way (CRM and Paraşüt)

A two-way sync also pulls information back, most usefully whether an invoice has been paid, so the salesperson sees payment status on the customer card without opening the accounting app. It is more powerful and more dangerous, because now both systems can change the same record and you need a rule for who wins a conflict. Before you enable it, read our guide to two-way data synchronisation, which covers the last-writer-wins and field-level ownership patterns that keep two-way links from overwriting good data with stale data.

What actually syncs: contacts, current accounts, invoices

An integration is only as good as the objects it moves, and three matter here.

Contacts and current accounts

A CRM contact and a Paraşüt current account are two views of the same entity: one tracks the relationship, the other tracks the balance. Syncing them means a customer created in Rocketly appears as a current account in Paraşüt with the tax office, tax number and address already filled in, and the running balance can flow back so sales can see who is overdue. That balance is the front line of collections; if you want a framework for handling the ones that go bad, see how to approach doubtful receivables and provisions before an overdue account quietly becomes a write-off.

Invoices and e-documents

Invoices are the payload everyone actually cares about. A well-built connection lets an invoice be prepared from CRM data (line items, quantities, the agreed total) and issued through Paraşüt as a proper e-Invoice or e-Archive document, then linked back to the deal so the whole story sits in one place.

When a won deal becomes an invoice draft

The moment that makes the integration feel magical is deal closure. When an opportunity is marked won in Rocketly, the connection can automatically assemble a matching invoice draft in Paraşüt: the right customer, the products from the deal, the quantities and the total, all pre-filled.

Note the word draft. You almost never want a won deal to fire off a legally binding e-Invoice with no human in the loop, because a stray click would then commit a real fiscal document. A draft gives someone a three-second review (is the address right, is the VAT rate correct, should this be split into two documents) before they hit issue. This works best when your pipeline is clean and your stages mean what they say; if won sometimes means maybe, tighten up your deal management and win probability first, because the automation will faithfully invoice whatever you tell it is won.

Avoiding double entry and duplicate records

The whole point is to enter each fact once. The failure mode that quietly ruins that promise is duplication: the same customer existing twice, once as ACME Ltd and once as Acme Limited, so the balance splits across two current accounts and no one can see the real total. Getting the match key right is everything.

• Match on a stable identifier, the tax number, not the display name, which people type differently every time.
• Decide up front which system owns customer creation, so new records are born in one place and mirrored to the other.
• Normalise before you sync: trim whitespace, standardise the tax office name, strip stray characters from phone numbers.
• Run a de-duplication pass on your existing data before switching the connection on, not after.
• Set the connection to update-if-found rather than always-create, so a returning customer never spawns a twin.

If your CRM already carries duplicates, clean them first; our walkthrough on finding and merging duplicate records covers the merge logic so you do not simply copy the mess into your accounting system at speed.

Field mapping and data hygiene

Two systems rarely name things the same way. Paraşüt expects a tax office, a specific address structure and its own product catalogue; your CRM has its own fields, some of them custom. The integration lives or dies on how carefully those fields are lined up, which is a discipline in itself; see our primer on field mapping for the full method.

The practical rules are simple. Map required fields first and make them mandatory in the CRM so a record can never sync half-formed. Keep the product list aligned on both sides, ideally by matching on a code rather than a name. And be explicit about VAT: the rate belongs to the product or line and must survive the trip intact, because a silently changed rate is the kind of error auditors find.

e-Invoice, e-Archive and staying compliant

In Turkey, invoicing is not a private matter between you and your customer; it runs through the Revenue Administration's e-document rails, and which rail you are on depends on your turnover and registration status. The rules and thresholds move, so it is worth keeping current with a resource like our overview of e-Invoice and e-Ledger thresholds rather than relying on what was true two years ago.

An integration does not make you compliant on its own; it makes compliance repeatable. The rules still have to be right, and the connection just stops you re-typing them wrong.

Practically, this means letting Paraşüt do what it is good at (issuing the correct document type, applying the right scenario, handling the exchange with the tax authority) while Rocketly supplies clean, complete customer and line data. Keep the human review step for anything unusual, and never let automation issue final documents for edge cases it was not designed to judge.

Monitoring the connection so it fails loudly

Every integration eventually hiccups: a token expires, an API changes, a customer record is missing a mandatory field and a sync silently stalls. The danger is a connection that fails quietly, so you only discover the gap at month-end when a week of invoices never made it across. Treat the link as production infrastructure and watch it the way you would any other, using the practices in our guide to integration monitoring: alerts on failed syncs, a visible queue of pending documents, and a periodic reconciliation of counts on both sides.

A practical setup checklist

Start small and widen. De-duplicate both systems, agree on the tax number as your match key, and map your required fields and product codes before anything flows. Turn on one-way sync first and watch it for a full billing cycle. Introduce the won-deal-to-draft automation once you trust the data, and keep the human review on every draft. Only then consider pulling payment status back with a two-way link, with an explicit conflict rule. Add monitoring on day one, not after your first silent failure.

Done in that order, the connection stops being a risky big-bang and becomes a quiet upgrade: your team sells in Rocketly, your accountant works in Paraşüt, and no tax number is ever re-typed. To see the sales side of that flow, you can create a free Rocketly account and connect your pre-accounting from there.