We’re looking for a Make.com specialist to build an automated workflow that connects our Mirakl marketplace seller account to our accounting platform Billit.
What it needs to do:
Periodically retrieve orders from our Conrad marketplace account via the Mirakl Orders API
Automatically create and send corresponding sales invoices in Billit (which delivers them via Peppol)
Handle credit notes for confirmed returns
Log processed orders (order number, amount, status) to a simple Google Sheet
Important non-standard requirement: every invoice must be issued to one fixed business customer (our marketplace partner), never to the actual end consumer who placed the order — the end customer’s details only appear in a separate delivery address field. Please confirm you can handle this before quoting.
Full requirements, API references, and field-level specifications are in the attached brief. We’d like your confirmation this is feasible and an estimate of cost and turnaround.
We’re a UK-based Make Partner with extensive experience building API-driven integrations and automating accounting and marketplace workflows. We’ve worked with a wide range of ERP, CRM, finance, and e-commerce platforms, and are comfortable implementing custom business logic such as invoicing a fixed business customer while retaining the end customer’s details for delivery purposes.
Before I comment on feasibility and provide an estimate, may I ask where your business is based?
Hi Wessel, I’m Misha, a Make.com and AI automation developer. I can streamline your workflow by connecting your Mirakl marketplace to Billit. I’ll set up a Make.com scenario that periodically fetches orders from the Mirakl Orders API, creates invoices directed to your fixed business customer, and ensures that customer details only appear in the delivery address field. Additionally, I’ll implement a logging process to a Google Sheet to keep track of order statuses and amounts, and handle credit notes for returns. This architecture will ensure reliability, keeping a close eye on API responses and error handling. You can feel confident in a robust setup tailored to your needs. Portfolio: https://mikedevai.netlify.app/ | Telegram: Telegram: Contact @hely_chatbots | WhatsApp: +375293761570
The brief appears to contain one inconsistency worth resolving before implementation: Section 5 mentions invoice creation at order acceptance, while also requiring invoices only after complete shipment, with the SLA counted from shipment. I’d recommend confirming which rule is authoritative. My assumption for the pricing below is invoice generation after the order reaches fully-shipped status (all lines, full quantities) — that satisfies both the no-partial rule and the 24-hour SLA.
To answer your explicit question: yes — the fixed-customer model is straightforward in Billit. The invoiced party is your configured Conrad NL entity, with the customer identifier type set to KVK (not the CBE default that appears in Billit’s sample payloads), Conrad’s PO number in the header Reference and repeated per line via the InvoiceLine.Note custom field, and the end consumer appearing only in the delivery-address block. I’ve spent 20 years building billing/ERP integrations — “invoice goes to the partner, goods go to the consumer” is standard drop-ship invoicing, not an exotic case.
The design goal in one line: every fully-shipped Conrad order becomes exactly one Peppol invoice to Conrad, exactly once.
The build: a scheduled scenario every 2-3 hours pulls orders from the Mirakl Orders API with status/date filters; a data store keeps processed order IDs, so re-runs and API hiccups can never produce a duplicate invoice; each invoice line carries the Conrad Product SKU and the Mirakl order number; confirmed returns generate a credit note referencing the original invoice. Anything abnormal — missing SKU, Billit/Peppol rejection, amount mismatch — lands in the Google Sheet as an exception row instead of failing silently. The mapping layer is kept separate from the flow logic, so partial-shipment invoicing can be added later without a rebuild. This is a straightforward API-to-API integration — the complexity is in the business rules, not in the automation platform itself; both Make.com and n8n handle it well.
Fixed price: EUR 700
Delivery: 6 business days
Days 1-2: one live Mirakl Orders API call to verify the Conrad Product SKU is already included in the order payload (your Section 6.1), plus a field-mapping sheet for your sign-off before anything touches Billit. If the SKU isn’t there, we’ll know immediately that the additional lookup is required.
Includes: written documentation + 30 days of post-delivery fixes.
Which platform do you lean towards — Make or n8n? I’ll tailor the field-mapping outline accordingly.
Wessel, I read the full brief. This is feasible in Make, including the fixed-customer model: every Billit invoice can use the configured Conrad NL entity and KVK identifier as the buyer, while the Mirakl end customer is mapped only into the separate delivery-address block.
I would treat order acceptance as the ingestion trigger, then hold invoice creation until every line is fully shipped. That reconciles the two rules in Section 5 while preserving the 24-hour shipment SLA. A Make data store keyed by Mirakl order ID would prevent duplicate invoices; confirmed returns would create a credit note tied to the stored Billit invoice reference.
The first checkpoint would be one live Mirakl Orders API call to verify Conrad Product SKU availability and approve the field map before any Billit write. Acceptance testing would cover a not-yet-shipped order, a fully shipped order, a replay with no duplicate, a confirmed return, the fixed buyer versus delivery-address mapping, and an API/missing-field exception logged to Google Sheets.
TinyOps Studio recommends Make for this scope because it keeps the HTTP calls, schedule, state, and operator log easy for your team to inspect. Fixed price: EUR 625. Delivery: five business days after test access and field-map approval. This includes the production scenario, concise runbook, test evidence, and 30 days of post-delivery fixes.
Terms are 50% to schedule the build and 50% after sandbox acceptance, before production activation. If that works, DM TinyOpsStudio and I will send the one-page milestone and acceptance checklist plus a private business checkout.
Hello @wessel_van_erk, Section 4 is feasible, and simpler than it sounds: since Conrad’s details are fixed config rather than order data, the invoice customer never varies, only the delivery address does. Proof, not just a claim: https://mirakl-billit-mapper-0728.netlify.app, edit the sample order’s end customer and watch the invoice customer stay Conrad while only delivery moves.
One contradiction worth clarifying: Section 5 says the trigger is order acceptance, not shipment, but the next bullet says to wait for full shipment. Which one actually fires the invoice? I’ve assumed full-shipment for this estimate.
Recommended platform: Make.com (Sign in | Make HQ, I’m a certified Make.com partner). Both APIs are plain REST/JSON with no dedicated app, so this runs on Make’s HTTP module against both, with its Data Store for dedup and Google Sheets module for the log.
Two things I’d verify with live test calls at the start: whether Conrad’s SKU is already in Mirakl’s order data (6.1), and what exactly signals a confirmed return.
Estimate: $1,600 fixed, 2-3 weeks, these are real e-invoices over Peppol so I want to test properly before it runs unattended.
Hi Wessel — yes, the fixed-customer model is feasible in Make.
I would configure Conrad NL once as the invoice customer (including KVK identifier and the fixed 21% VAT logic), map the actual consumer only into the separate delivery-address block, place Conrad’s PO in Billit Reference plus the line-level CustomFields note, and never derive the Billit customer from the Mirakl buyer record.
One important detail I caught in the brief: it says the trigger is order acceptance, but also says not to invoice until the complete order has shipped. I would ingest and track the order from acceptance, then release the Billit invoice only when every line/quantity is fully shipped, still meeting the 24-hour post-shipment SLA. Please confirm that interpretation.
Recommended build:
scheduled Mirakl Orders API polling with pagination/date/status cursor;
first live call verifies Conrad Product SKU vs Offer SKU before final mapping;
a persistent state record keyed by Mirakl order ID for idempotency, status, payload hash and Billit reference;
separate Invoice and Creditnote paths, with credit notes linked to the original invoice only after the confirmed-return state;
Google Sheets as the human-readable report, not the sole duplicate-prevention database;
retries/incomplete executions, actionable failure alerts, test pack and handoff notes.
I recommend Make for this phase because the workload is scheduled REST/JSON orchestration and the hosted runtime reduces maintenance. I would keep the mappings modular so partial-shipment invoicing can be added later.
Estimate: €1,350 fixed and 7 business days after access to a test/sandbox path. I’d split it into a €250 API/mapping milestone (credited to the total) and €1,100 for build, testing and handoff. The first milestone protects both sides if the Product SKU or Billit delivery-address behavior differs from the documentation.
My background combines accounting operations and workflow automation. I use an AI assistant for research, QA checklists and documentation; I remain the human accountable for every mapping, test, security decision and delivery. I do not need passwords posted in the forum—access can be granted through normal collaborator/credential controls after agreement.
Wessel — this is technically feasible in principle, including the fixed Conrad customer with the end consumer retained only as the delivery address. I found one rule in the brief that should be resolved before anyone treats a production quote as final: it refers to order acceptance as the trigger but also says to wait for full shipment. Which event is authoritative?
I would start with a $799 paid validation gate delivered in five business days. It verifies your actual Mirakl order/refund fields, the fixed-customer/VAT mapping, Billit test access and Peppol registration in the test environment, one normal-order result, one credit-note result, duplicate protection, and visible failure cases. You receive the mapping, run evidence, risk list, and fixed phase-two scope.
The full $799 is credited toward the production build if you approve that separately within fourteen days. If validation confirms the brief’s assumptions, my target is a $1,600 total fixed project price, with the validation fee credited, and an additional seven-business-day implementation window. If the evidence changes the scope, you decide whether to continue before any additional payment.
Before I accept payment: (1) is Peppol active specifically in your Billit test environment, (2) can you provide Mirakl sandbox access or sanitized order/refund exports, (3) can you provide one sanitized successful invoice and credit-note example, (4) is order acceptance or full shipment the true invoice trigger, and (5) who approves the VAT, rounding, fixed-customer, and item mapping?
I am not claiming prior Mirakl/Billit production work. The first milestone exists to prove the account-specific facts and prevent an untested Peppol workflow from being presented as complete.
Wessel, I built a sample-only mapping proof for the core rule in your brief. Change the fictional end customer, run a fully shipped order, then replay it: the Billit buyer remains fixed to Conrad NL, the delivery block changes separately, and the duplicate run is skipped. Clearing the sample SKU also shows the exception path before any Billit write.
No live APIs, credentials, invoices, or customer data are connected to the demo. My EUR 625 fixed price, five-business-day delivery, and the first read-only Mirakl field check remain unchanged.
I read the full brief. The fixed-customer model is feasible in Make: Conrad remains the invoice customer, while the end consumer is mapped only into the separate delivery-address block. I would ingest the order at acceptance, but release the invoice only after every line and quantity is fully shipped.
There is one lifecycle detail I would define before treating the Google Sheet status as “success”.
A successful POST /v1/orders only confirms that Billit created the document and returned an OrderID. Peppol delivery continues asynchronously. The invoice may then move through Sent, Accepted, Delivered or Refused.
I would therefore store the Billit OrderID and use Billit’s Message webhook to maintain a real document state:
Any refusal reason would be written to the operator log. Otherwise, the Make scenario could finish successfully while the invoice never actually reaches Conrad.
My proposed build would include:
Mirakl polling with persistent order state and duplicate protection
fixed Conrad buyer and separate delivery-address mapping
invoice release only after complete shipment
stored Billit invoice reference and Peppol status reconciliation
credit notes linked to the original Billit invoice
Google Sheets as the human-readable operational log
sandbox tests for delivery, refusal, replay and confirmed returns
Based on the current brief, my estimate is €1,100 fixed and 7 business days after test access and field-map approval. I have not deployed this exact Mirakl and Billit pairing, so the first checkpoint would be a read-only Mirakl order call and one Billit sandbox transaction before any production write.
One question would determine the final acceptance criteria: is your 24-hour SLA satisfied when Billit creates the invoice, when Peppol reports Sent, or only when it reports Delivered?
Zay
Hi Wessel — I read the brief. The fixed-customer model is feasible in Billit’s order schema: Conrad stays the invoice customer, while the Mirakl end customer is mapped only to the separate delivery address.
Section 5 currently conflicts: it says invoice creation is triggered at order acceptance, but also says to wait until every line is fully shipped. I would ingest and deduplicate at acceptance, then release only after the authoritative status check you confirm.
My proposal is €749 fixed, delivered in 7 business days after sandbox access, starting with a funded €249 two-day validation milestone. That first milestone uses one sanitized order and one confirmed-return fixture to verify the Conrad Product SKU field, fixed Conrad/KVK and 21% VAT mapping, one invoice payload, one credit-note payload, duplicate suppression, and visible failure cases. No production invoice or Peppol send is included in validation. I have hands-on experience with Make, APIs, webhooks, and workflow reliability; this is not a claim of prior Mirakl/Billit delivery. Work starts only after written scope and the first milestone payment clears.
If this structure fits, reply with the authoritative invoice event: order acceptance or complete shipment.
Reading the brief, the part that will decide whether this is stable is idempotency, and it isn’t in there yet.
Mirakl’s Orders API is polled, not pushed. If you drive it off a date window, any retry, any scenario re-run, any clock skew on the boundary re-issues invoices that Billit has already sent through Peppol — and a Peppol invoice is not something you quietly delete. So the order log you’re describing in Sheets shouldn’t be a report; it should be the ledger the scenario checks before it creates anything. Order number as the key, written before the Billit call, not after.
Three more that follow from the same place:
Watermark on last_updated rather than a fixed lookback, so a slow day and a backfill behave the same way
Credit notes referenced to the original invoice number, which means the ledger has to store Billit’s returned document ID, not just “sent”
Peppol delivery status written back to the same row — Billit accepting a document and Peppol delivering it are two different events, and you’ll want to know which one failed
The fixed-customer model is straightforward once the above holds: the invoice header is constant, the line items carry the marketplace order reference so your accountant can still trace a payout back to orders.
I build exactly this kind of thing — API-to-accounting plumbing where correctness matters more than cleverness. Happy to look at the Mirakl account’s actual order shape and quote a fixed price per deliverable rather than an hourly guess.
Async, Paris CET, remote-only delivery — written briefs over meetings.